CEBus Demystified: The ANSI EIA 600 User's Guide

CEBus Demystified

This page intentionally left blank.

User’s GuideGrayson Evans

McGraw-HillNew York • Chicago • San Francisco • Lisbon • London

Madrid • Mexico City • Milan • New Delhi • San Juan • SeoulSingapore • Sydney • Toronto

CEBus DemystifiedThe ANSI/EIA 600

United States of America. Except as permitted under the United States Copyright Act of 1976, no partof this publication may be reproduced or distributed in any form or by any means, or stored in a data-base or retrieval system, without the prior written permission of the publisher.

All trademarks are trademarks of their respective owners. Rather than put a trademark symbol afterevery occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefitof the trademark owner, with no intention of infringement of the trademark. Where such designationsappear 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 pro-motions, or for use in corporate training programs. For more information, please contact GeorgeHoare, Special Sales, at [email protected] or (212) 904-4069.

TERMS OF USEThis is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensorsreserve all rights in and to the work. Use of this work is subject to these terms. Except as permittedunder the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may notdecompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon,transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it withoutMcGraw-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 youfail to comply with these terms.

THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUAR-ANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OFOR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMA-TION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE,AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUTNOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the func-tions contained in the work will meet your requirements or that its operation will be uninterrupted orerror free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inac-curacy, 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 thework, even if any of them has been advised of the possibility of such damages. This limitation of lia-bility shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tortor otherwise.

abc McGraw-Hill

Copyright © 2001 by The McGraw-Hill Companies, Inc. All rights reserved. Manufactured in the

0-07-141465-7

The material in this eBook also appears in the print version of this title: 0-07-137006-4.

DOI: 10.1036/0071414657

Want to learn more?

We hope you enjoy this McGraw-Hill eBook! If you’d like moreinformation about this book, its author, or related books andwebsites, please click here.

Notable Conventions

CEBus CEBus Standard

According to guidelines published by the EIA, the trademark “CEBus” isan adjective, not a noun. “CEBus” should always be used with the word“standard,” “compliant,” or other appropriate word since CEBus refersonly to the ANSI/EIA-600 standard. A product that complies withANSI/EIA-600 should be referred to as a “CEBus standard compliant”product, or “CEBus compliant.” However, to make this book easier toread (and to write), the word “standard” is often implied. Wherever theword “CEBus” is used, assume this means “CEBus Standard.”

In this book, CEBus, EIA-600, and ANSI/EIA-600 are used to refer tothe same official standard: ANSI/EIA-600

Conflicts with the CEBus Standard

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

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


CONTENTS

Chapter 1 1

What Is CEBus? 2

Why Residential Networks? 3

Why Make a Standard? 5

CEBus Development Goals 6

Development History 6

This Book’s Goals 8

How This Book is Organized 8

Chapter 2 CEBus Document Overview 11

EIA-600 12

EIA-600 Attributes 12

The Standard Parts 13

An Introduction to EIA-600 Parts 16

The Physical Layers 16

The Protocol 17

The Language 18

The Design Constraints 19

Security Issues 20

Chapter 3 The CEBus Benefit 23

The Benefits of Networked Products 24

What CEBus Products Say 25

Control Messages 25

Status Messages 26

Typical CEBus Applications 26

The Future Potential 28

The Plug-n-Play Concept 29

Interoperability Defined 30

Communications Level Interoperability 30

Application Level Interoperability 31

Scenario Interoperability 33


Introduction

For more information about this title click here.

viii Contents

Chapter 4 CEBus Basics 35

How CEBus Works—An Overview 36

The CEBus Product Model 36

Nodes 37

Network Communications Models 40

Network Control Model 41

CEBus Reference Architecture and Media 42

Channels 44

Packets and Messages 47

Symbol Encoding 48

Network Attributes 50

CAL:What CEBus Products Say to Each Other 51

CAL View of Products 51

Chapter 5 The Media and Physical Layers 53

The CEBus Network Topology 54

Architecture Assumptions 54

Node O 55

Router and Brouter Requirements 56

Medium, System, and Global Networks 60

Connection to the Outside World 61

The PL Network 62

Power-Line Topology 62

CEBus Signaling on the PL 64

Packet Encoding 67

Physical Layer Implementation 68

PL Performance 70

The TP Network 71

TP Cable and Wire Use 71

TP Control Channel 74

TP Physical Layer 75

The CX Network 76

The Cable 77

CX Network Topology 78

Cable Connectors and Outlets 79

Node O Distribution Device 80

Coax Control and Data Channels 81

CX Physical Layer 83

CEBus RF 84

CEBus RF Signaling 84

Contents

RF Control Channel Encoding 85

RF Physical Layer 87

Chapter 6 Protocol 91

A Little Protocol Background 92

CEBus Protocol Overview 92

The ISO vs. CEBus Model 95

The Peer-to-Peer Layer Model 95

Transmission Failures 97

Application Layer vs. the Application 98

Packet Format 98

Layer Responsibilities 99

Application Layer 99

The APDU Header 101

Basic Service APDU 101

Extended Service APDU 103

Basic Service Details 105

Explicit_Invoke Service 105

Synchronous Service and the Invoke_IDs 110

Reject APDUs 112

When to Use What Service 112

Application Layer Extended Services 114

Authentication 115

Authentication Algorithms 116

Encryption 117

Using Secure Services 117

Network Layer 118

The NPDU Header 119

Network Layer Extended Services 122

More on IR/RF Packets and Duplicate Rejection 130

IR/RF Packet Examples 131

ID Packets 133

Data Link Layer 135

DLL Structure 136

Packet Format 137

EOFs, EOPs, and Leading Zero Suppression 139

Channel Access Protocol 140

DLL Packet Delivery Services 145

Unacknowledged Service 146

Addressed Unacknowledged Service 146

ix

x Contents

Addressed Unacknowledged Sequence/Address Association 147

Acknowledged Service 148

The Physical Layer 154

The PL and RF Medium SES 156

CEBus Addresses 157

The System Address 157

The Node Address 158

Acquiring and Keeping Addresses 160

Implementation Issues 160

Layer System Management 161

Chapter 7 CAL 163

CAL Goals 164

How CAL Models the Consumer Product World 165

The Context Data Structure 166

Contexts 166

Objects 167

Object Definitions 171

Context Data Structure 178

Object Network Types 179

Object Binding: How Contexts Work Together 180

Context Examples 185

The Universal Context 186

Context Control Object 190

Determining Product Capability 191

Where Do Contexts Come From? 191

Messages: Object Communications 192

Command ASDUs 192

Response ASDUs 193

Methods 195

Message Generation 199

Implementation Example 204

Resource Allocation 204

Address Resources and Address Allocation 205

Node Addressing 207

Address Self-Acquisition 208

The CAL Interpreter 213

Transporting Non-CAL Messages 214

Generic CAL (ANSI/EIA.721) 215

Differences between Generic and CEBUS CAL 215

Contents

Chapter 8 Interoperability and HomePnP 220

HomePnP Overview 220

Some New Ideas 222

Interoperability and HomePnp 223

State Vectors 224

Configuration 225

Additional Problems Addressed by HomePnP 225

Chapter 9 Product Development 227

Design Considerations for Networked Products 228

Security 229

Addressing 230

Interoperability 231

Partitioning of Processing Tasks 232

Creating CEBus Applications: An Overview 234

The Design Problem 235

Getting It Built 244

Product Benefits 245

Minimum Requirements—Deciding What to Implement 246

Data Link Layer 246

Network Layer 247

Application Layer 247

CAL 248

Certification (ANSI/EIA-633) 249

Plug Lab 250

Appendix A Object Definitions 251

Common Object IV Labels 251

Manufacturer IVs 252

Object Tables 252

Object Categories 252

Table Notes 253

03 Data Channel Receiver 254

04 Data Channel Transmitter 255

05 Binary Switch 256

06 Binary Sensor 256

07 Analog Control 257

08 Analog Sensor 258

09 Multiposition Switch 259

xi

xii Contents

0A Multiposition Sensor 260

0B Matrix Switch 261

0F Meter 262

10 Display 263

11 Medium Transport 264

13 Dialer 265

14 Keypad 266

15 List Memory 267

16 Data Memory 268

17 Motor 269

19 Synthesizer/Tuner 270

1A Tone Generator 271

1C Counter/Timer 272

1D Clock 273

Appendix B Sample Contexts 275

Context 10 (Audio) 275

Context 21 (Light) 280

Appendix C Response Error Codes 285

Appendix D CEBus Resources 287

Index 289

CEBus Demystified


Introduction1CHAPTER 1


2 Chapter One

In April 1984, 12 people representing 12 member companies of the Elec-tronics Industries Alliance (EIA) met in a hotel room in Washington,D.C. They were there at the invitation of the EIA Consumer ElectronicsGroup to help formulate some form of common communication stan-dard for consumer devices used in homes. This standardization effortwas a result of an earlier attempt to develop a common infrared remotecontrol standard.

If these 12 men had any idea that they were about to begin a task thatwould occupy a considerable portion of their lives—and the lives ofdozens of others—for the next 10 years, it is unlikely that they wouldhave continued the task. But, of course, they could not possibly haveknown what they were about to undertake.

What these people started is known as the Consumer Electronic Bus(CEBus) home automation communication standard—a standard thatdefines a communications protocol, language, and media interface speci-fication that enables any device in the home to communicate with anyother device.

The CEBus effort, which culminated in 1992, was an impressiveaccomplishment. No other standard-setting activity that the EIA hasever undertaken approaches CEBus in scale and complexity. More than400 people and companies were involved in the successful developmentof 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. Thestandard specifies how products send and receive information, the media available to use the products, and what products say to eachother.

CEBus solves the traditional problems of integrating products andsystems made by different manufacturers by establishing a standard,reliable interface to each CEBus-compliant product in the home. Thestandard provides

A standardized physical interface between devices in the home sothat information can be easily and reliably exchanged

A standardized way for devices to interoperate and “talk” to eachother using a common language

Introduction

CEBus enables stand-alone products to become networked products,sharing information and product “resources.” Its standardized commonlanguage ensures built-in interoperability and a rich set of capabilities.

CEBus also establishes a unified, high-quality cabling standard to han-dle all of the data communication needs of the home (audio, video,CEBus product communications, computer data, etc.) for the foreseeablefuture. The cabling standard has become the basis for all current resi-dential infrastructure wiring products and was the basis of the revisedANSI/TIA/EIA-570A residential wiring standard.

Why Residential Networks?During the 1990s, there was a growing need to solve a related set of com-munication problems in the home. These problems are the result of newtechnology products in the home (such as home computers, homeautomation systems, home theater, energy management systems, andtelecommunication products) and the rise of wideband serviceproviders. Deregulation of the communication industry in the UnitedStates has created new market opportunities for service providers to offeraccess to a host of wideband information “services.” Cable TV companiescan now provide telephone and other high speed two-way communica-tion services. Telephone companies can provide cable TV services such aspay-per-view movies and information services, as well as voice and datacommunications. Utility companies can provide appliance monitoringand energy management services, and can offer variable electric ratesbased on their access to and ability to control in-home appliances.

These new technologies depend on reliable communications in thehome. Present residential wiring will not be capable of providing theseservices due to the poor quality of most existing in-home telephone andcoaxial cable. A new residential network technology is needed. The net-work must provide three things:

A universal, low-cost method for devices in the home to communicateregardless of manufacturer. There must be a way to distribute controland data about the operation of appliances and systems throughoutthe home. This information allows products to interoperate—sharing information such as time and temperature, the currentelectric rate, house occupancy, and so on. Without this capability,there can never be a reasonable market for home automation.

3

4 Chapter One

A reliable way to provide for in-home distribution of wideband (widearea network) outside services. Wideband services can be broadlycategorized as part of the “information superhighway.” Theseservices include delivery of digital telephony, pay-per-viewvideo, interactive gaming, electrical load management, “housesitting,” computer network access, and the like. These serviceswill arrive at the home via the local cable company, thetelephone company, the power company, and wireless (RF)service providers. Many of these services require bandwidthsthat are not supportable with the present wiring (telephone,cable) in the majority of homes.

A reliable way to distribute wideband services that originate fromproducts in the home. There must be a way to distribute in-home-generated information. This includes video and data frommultimedia computers, home theater equipment, VCRs, securitycameras, audio equipment, and the new generation of high-tech“set-top boxes.” Audio and video distribution is becomingincreasingly important as consumers become more mediaoriented.

CEBus meets all of these needs by forming a local area network in thehome for the distribution of in-home and outside data and services. Thenetwork has these characteristics:

Provides for distributed rather than centralized control

Supports the distribution of audio, video, and data, as well ascontrol messages

Uses a variety of physical transmission media

Provides a flexible application language

Enables very-low-cost implementations that are intended forconsumer products

CEBus delivers a common product interface and a common networkinfrastructure. It specifies completely the use of the power-line wiring(PL), radio frequency (RF), and infrared (IR), and the installation and useof twisted-pair (TP) and coaxial (CX) cable. The standard is flexibleenough to allow CEBus compliant products to be used in existinghomes using the PL, RF, IR, and most existing TP wiring. The standardcompletely specifies how products connect to the network and the com-munications protocol.

Introduction

Why Make a Standard?The committee members understood that future consumer productswill be interconnected and that future capabilities will demand access todata and control information from outside the home and between prod-ucts in the home. A standard for product interconnection is inevitableto 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 andother companies copy it—or from a standards-setting organization (EIA,IEEE, or ANSI) at the request of an industry group of companies. In thecase of a residential product standard, one that interconnects all prod-ucts in the home, there is no one product category that could dictate astandard, similar to how IBM and Microsoft standardized the personalcomputer industry. There are too many unrelated product categories.Because no one product manufacturer is dominant enough to generatea de facto standard, it had to come from a standards organization.

To establish a standard from “scratch,” it is essential to set the require-ments up front and ensure that there is agreement from all participantsbefore undertaking the technical details. The three requirements forCEBus that were established early in the process are:

1. To allow introduction of new products and services to homes at minimumcost and confusion to consumers. This is the whole point of CEBus. Itis designed to remove the entry barrier for products that cancommunicate. The standard opens the potential for hundreds ofnew products and services for the homeowner, but it must do sowithout causing confusion in the marketplace.If the committee on the CEBus technology used a litmus test, it isthe test of “…minimum confusion to consumers.” A reliablenetwork technology that is installable by the average homeowneris difficult. Some confusion is inevitable, but every effort wasmade to minimize any additional confusion.

2. To meet the majority of anticipated home control and informationdistribution requirements with a single multimedia network standard.CEBus had to handle the control requirements of all existingappliances and products in the home, as well as any future devicethat manufacturers might think up. It must be usable on any or allof the media present in the home, such as the power line or

5

6 Chapter One

telephone wiring. It must handle the bandwidth requirements fordistribution of outside services to any device in the home.

3. To minimize the redundancy of control and operation methods amongproducts in the home. In theory, CEBus can actually simplify theoperation of appliances and products in the home by enabling acommon interface to develop. For example, CEBus has thecapability to enable a television to present menus to allow settingof thermostats, microwave ovens, VCRs, security systems, and thelike, with a common onscreen interface.To meet the requirements for CEBus, the technical goals for thetechnology were clear: it must be retrofittable; it must supportdistributed intelligence; it must not be product specific; it musthave an open architecture; and it must be expandable. The goals were met by IS-60, and products demonstrating thecapability were built.

CEBus Development GoalsA stated motivation for developing CEBus is to encourage new companiesto enter, or reenter, the consumer electronics business. CEBus is viewedby many of its developers, including the EIA, as a major commitment tohelp U. S. companies regain a foothold in consumer product manufactur-ing. The standard will spur the development of literally hundreds ofnew consumer products, and provide an opportunity for small and start-up companies to get into (or back into) the consumer electronics busi-ness. By providing an open yet controlled standard, CEBus opens thehome automation market to a large number of new product ideas—mostpreviously unthought of. You will, undoubtedly, see a host of new prod-ucts from many new (and existing) companies that have decided to enterthe market due to the perseverance of the EIA and the CEBus committee.

Development History

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

Introduction

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 ofworking groups.

1985—The committee started work on a field-test program to determinethe characteristics of residential power-line wiring systems by takingactual measurements from hundreds of homes throughout the coun-try. A Language Working Group was formed to begin work on a com-mon product command language.

1986—The committee adopted Homenet (GE’s power-line protocol thatGE had developed for HomeMinder) for the foundation of the CEBusprotocol. “CEBus” became the de facto name for the standard.

1987—Early versions of the PL physical layer were built using the 1 KbpsASK technique and preliminary testing was performed in severalhouses.

1988—In early 1988, the committee decided to demonstrate CEBus in abooth at the 1989 Winter Consumer Electronics Show. The first passof the language protocol and PLBus physical layer specification wascompleted.

1989−1990—The first versions of the TPBus, CXBus, SRBus, Node 0, andApplication Layer documents were completed. The ASK PLBus and protocol specifications were released for industry ballot, markinganother major milestone.

1991—The Intellon spread-spectrum transceiver technology was selectedto officially replace the existing ASK PLBus standard. The new PLspecifications were completed in draft and released for ballot.

1992—On November 6, the CEBus Committee held its sixty-seventhmeeting in Victoria, B. C., Canada. IS-60 became an official EIA docu-ment.

1993—The EIA incorporated the CEBus Industry Council (CIC) to serveas a cross-industry association for companies developing CEBus prod-ucts and services.

1995—IS-60 underwent a final review of changes in an effort to becomea joint ANSI/EIA standard: EIA-600. Each part of the standard wasreballoted 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 inde-pendence, was released as ANSI/EIA-721.

7

8 Chapter One

This Book’s GoalsThis book was written to supplement the EIA CEBus standard docu-ment. While this book may be all you want to know about the stan-dard, it does not eliminate the need to consult the EIA-600 document ifyou plan to develop CEBus products or adapt an existing product. Thedetailed specifications in the standard are essential. Rather, this book isdesigned to make the standard understandable. It provides a technicaloverview for nearly all sections of the standard, and provides implemen-tation information that is not available elsewhere. The book providesmany diagrams, tables, and explanatory material that will prove benefi-cial in getting the most from the standard documents.

This book covers only the Node communications protocol, the proto-col intended for consumer devices. It does not cover the Router andBrouter communications protocols described in Volumes 5 and 6 of thestandard. However, because the Router and Brouter protocols are a modi-fied subset of the Node protocol, they should be easy to understandonce you understand the operation of the Node protocol.

How This Book Is OrganizedChapter 2, CEBus Document Overview, provides introductory materialon the standard, including an overview of the CEBus documents, howthe standard is organized, the design goals, the design constraints, thetarget environment, and how the goals were achieved. It also contains abrief development history.

Chapter 3, The CEBus Benefit, details some typical applications,describes residential network goals and advantages, and what problemsCEBus solves.

Chapter 4, CEBus Basics, provides a technical introduction to networkconcepts, terminology used in the standard, and an explanation of someof the basic technology adopted in CEBus. You should read this chapterbefore you read Chapter 6, 7, or 8.

Chapter 5, CEBus Media and Physical Layers, describes the physicallayer portions of the standard, including network topology, symbolencoding, the physical layer interface to each media, and the electricaland mechanical requirements of each medium. This chapter covers mostof the material given in EIA-600.3 (PL/RF Symbol Encoding, SymbolEncoding, PL, RF, IR, CX, TP, and Node 0).

Introduction

Chapter 6, CEBus Protocol, describes the network protocol used byCEBus. This chapter provides an overview of the protocol requirementsand of the basic attributes of the protocol used by CEBus, and coversthe requirements of each nonphysical protocol layer (Data Link, Net-work, and Application). This chapter covers most of the material inEIA-600.4.

Chapter 7, CAL, provides a complete description of the CEBus lan-guage. The chapter describes how to use CAL, what products say to eachother, how messages are generated, CEBus product interoperability goals,and the design requirements of a CAL language interpreter. This chaptercovers most of the material given in EIA-600.8 (CAL Language). The chap-ter also includes an overview of the generic CAL specification(ANSI/EIA-721).

Chapter 8, Interoperability and HomePnP, provides an overview ofthe theory of interoperability, describes some of the problems inherentin product interoperability that CEBus does not address, and discusseshow the Home Plug-and-Play specification resolves these problems.

Chapter 9, Product Development, discusses the development processof making a CEBus-compliant product, including networked productconsiderations. This chapter uses what was learned previously in thebook to convert a traditional stand-alone product into a CEBus networkproduct.

The Appendix contains reference material on the protocol and CAL. Alist of CEBus resources (trade associations, manufacturers, consultingcompanies, and so on) is also given.

9


CEBus DocumentOverview

2CHAPTER 2


12 Chapter 2

This chapter introduces the standard documents and provides the neces-sary background material to understand why the standard is the way itis, and why certain design tradeoffs were made. The design constraintsof the residential environment set many design and operating limits onthe complexity of CEBus. The design goals and the design constraintsoften conflicted, thereby limiting the CEBus capability. However, nearlyall goals were met and the standard provides a high-speed, reliable com-munication network for a wide range of products in the home.

EIA-600The CEBus standard was developed by the Electronics IndustriesAlliance (EIA). The EIA is one of the oldest trade organizations in theUnited States, and is responsible for many of the consumer and com-mercial standards used by electronics industries throughout the world(for example EIA-232, EIA-485, telephone, television, radio, and audiostandards). CEBus is available for purchase, as are all EIA standards, fromGlobal Engineering as a two-volume set (see the Appendix for addressand number).

CEBus is just a document. While it specifies how all parts of the net-work are built and installed, it is neither hardware nor software, nor doesit describe how to build hardware or software. There is no such thing as“a CEBus.” There are only CEBus-compliant products and devices. Manu-facturers create or adapt existing products to comply with the hardwareand 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 CEBusdevices must perform, not how they are built. The standard givesonly the electrical and timing specifications of a CEBus device asseen from the network. The performance specifications arewritten in terms of the packet content, transmission timing,protocol performance, and network electrical and physicalcharacteristics.

CEBus Document Overview

It is open and nonproprietary. Open means that the development,review, and modification of the standard is available to anyonewith a legitimate business interest in the technical accuracy andusability of the standard. More than 400 companies havecontributed 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 continuedrefinement and support of the standard. The diversity ofsupporting companies contributes to the strength of CEBus.

It is a minimum requirement for compatibility. The CEBus standarddescribes those features and capabilities that must be implementedfor products to communicate reliably in the home using the CEBusprotocol. It allows for easy extensions as needs change and futureproduct categories are invented. It allows wide flexibility inimplementation. Manufacturers are free to meet the standard usingany combination of hardware or software, and by using existing ornew components.

The Standard Parts

The CEBus standard can be divided into three major areas: the physicalmedia and media topology (power line, coax, twisted-pair, and so on, andhow they are connected); the communication protocol (used for networkaccess 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 dividedinto numbered parts. The description of each volume in the followingparagraphs gives the EIA-600 volume/part number.

EIA-600.10 Introduction This volume covers the overview, back-ground, scope, and goals of the standard. It also includes a set of mini-mum requirements for CEBus-compliant products, and a set of wordusages and global definitions for the entire standard.

EIA-600.20 Description This volume provides an overview descrip-tion of the EIA-600 standard starting with the general architecture; adiscussion of the media and topologies used with each medium; andan overview of the message protocol and command language used by

13

14 Chapter 2

all EIA-600 devices. As of the publication of this book, this section wasstill incomplete.

EIA-600.30 Physical Layer and Media This volume consists of nineparts covering all of the EIA-600 allowed media and the physical layerinterface to the media (OSI Layer 1), plus a discussion of all network sup-port functions, including Router and Brouter physical layer descriptions.

EIA-600.31 PL, Physical Layer. Describes the physical layer interface require-ments for connection and use of the residential power-line wiring.

EIA-600.32 TP Physical Layer. Describes the physical layer interface require-ments for connection and use of twisted-pair cabling, including thetelephone wiring.

EIA-600.33 Coaxial Cable Physical Layer. Describes the physical layer inter-face requirements for connection and use of a coaxial cable network.

EIA-600.34 IR Physical Layer. Describes the physical layer interface require-ments for use of infrared as a single-room communications medium.

EIA-600.35 RF Physical Layer. Describes the physical layer interface require-ments 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 infraredphysical layers. The symbol-encoding sections are considered a “sub-layer” of the physical layer.

EIA-600.38 PL/RF Symbol Encoding Sublayer. Describes the requirementsfor network symbol encoding for the RF and PL physical layers.

EIA-600.39 Node 0. Describes the physical network support functions forpower, twisted-pair, and coaxial cable.

EIA-600.40 Node Communications Protocol This volume consistsof six numbered parts covering a complete description of the OSI proto-col layers used by EIA-600 and the resulting message packet format.

EIA-600.41 Data Link Layer Descriptions. Describes the requirements andfunctions of the Data Link portion of the protocol. The Data Linklayer 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 ofthe Medium Access Control sublayer in terms of a state machine


and its interface to the Logical Link sublayer and Symbol Encodingsublayers.

EIA-600.43 Logical Link Sublayer. Describes the functions of the LogicalLink sublayer in terms of a state machine and its interface to the Net-work and Medium Access Control sublayer.

EIA-600.44 Network Layer Description. Describes the requirements andfunctions of the Network portion of the protocol.

EIA-600.45 Network Layer. Describes the function of the Network layer interms of a state machine and its interface to the Application layer andData Link layer.

EIA-600.46 Application Layer. Describes the functions of the Applicationlayer and the state machine and layer interfaces. The Application definesthe interface to the user application (or user element) and the Networklayer. While the Application layer formally includes the CAL languageinterpreter function, it is described in a separate document (EIA-600.08).

EIA-600.50 Router Communication Protocol This volume consistsof four parts covering a complete description of the OSI layers necessaryto implement a Router function between EIA-600 physical media.

EIA-600.60 Brouter Communication Protocol This volume con-sists of four parts covering a complete description of the OSI layers nec-essary to implement a Brouter function between EIA-600 nonphysicalmedia (RF, IR) and physical media.

EIA-600.70 Supplemental Data This volume is reserved for anyfuture “supplemental data” found necessary to use or understand thestandard. It is presently not used.

EIA-600.80 Common Application Language This two-part volumecovers the high-level command language (CAL) used by all CEBus-com-pliant 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 ofthe application layer.

EIA-600.82 CAL Contexts. This part furnishes the four general CAL Con-texts (Universal, Data Channel, Time, and User Interface). The remain-ing contexts are the published Home PnP (Home Plug-and-Play) spec-ifications (see Chapter 8).

15

16 Chapter 2

An Introduction to EIA-600 PartsThe 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 con-nect to and transmit on the media, and the signaling technique used oneach media. While the communication protocol and language are com-mon to all CEBus devices, the installed media and topology may varyconsiderably from home to home depending on the needs and types ofdevices used in the home. Devices can connect to and communicateover any (or several) of the following media:

The existing 110/220V power-line (PL) wiring of the homeaccessible by devices that normally plug into an electrical outlet.

A four twisted-pair (TP), or four-pair, cable that can be used byCEBus-compliant devices that normally use low-voltage wiring(thermostats, security sensors, and the like), and communicationproducts (telephones and intercoms). The four-pairs (called TPpairs) can be used in place of the normal telephone wiring or cansupplement 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 Associationtelephone premise wiring standard and CEBus TP wiring aredesigned to be compatible.

A pair of coaxial (CX) cables used by CEBus devices normallyconnected to video cable such as TVs and VCRs. The coax pairdelivers CEBus messages, cable TV programming, and in-home-generated video (cameras, VCRs, computers) to any video device in the home. One cable in the pair is dedicated to externallyprovided widebandwidth services, and one wire is used todistribute in-home-generated signals.

Radio frequency (RF) communications throughout the homecentered at 915 MHz.

Infrared (IR) communications for line-of-sight distances (usuallysingle room) using IR wavelengths similar to hand-held remotes.


Due to the wide choice of media, existing homes can begin using thestandard as easily as new homes. An existing home can immediately usethe power line for new CEBus devices, and the devices obviously requireno installation tasks. As a family becomes comfortable with the technol-ogy and comes to rely on CEBus products, additional media can beretrofitted if desired.

New homes can begin to take advantage of the new and CX capabil-ity. The TP wiring requires a four-pair twisted telecommunicationscable (good quality telephone wire). Homes wired to the new telephoneindustry wiring standard (TIA-570) will be CEBus ready. The CXmedia standard requires the installation of a pair of coaxial cables(equivalent to RG-6), branched from a central location to each room orarea in the home.

The standard classifies the media into two groups: wired and non-wired media. The wired media are PL, TP, and CX. The nonwiredmedia are RF and IR. The different medium networks connect bydevices called Routers and Brouters. A Router is a two-way CEBus devicethat 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 con-nected medium. A Brouter is a two-way CEBus device that connects anonwired medium to a wired medium such as RF to PL. Messages thatoriginate on RF or IR are routed to a wired media. Routers andBrouters are required to make the different media used in a homeappear to each CEBus device as one medium. If a CEBus device trans-mits 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 networkprotocol used by CEBus is based on the ISO Open Systems Interconnect(OSI) seven-layer network protocol model. A protocol defines the formatof the data, or “packets,” sent and received by network devices; the accessto 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 andrequirements 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 standardfor protocol tasks.

17

18 Chapter 2

The Data Link layer (DLL) is responsible for the low-level task of reli-able message delivery on a single medium—the medium used by thedevice. It handles error detection, packet retransmission, address recogni-tion, packet timing, and buffering. The DLL is defined in two separatedocuments: the Medium Access Control sublayer (MAC), and the LogicalLink Control sublayer (LLC). These documents divide the DLL responsi-bilities into separate parts, although this is only a documentation conve-nience. The MAC handles most of the layer tasks; the LLC is little morethan an interface with the Network.

The Network layer is responsible for reliable message delivery acrossnetwork media. It handles medium selection, routing, and duplicatepacket rejection for packets that originate on a nonwired medium. TheNetwork layer also is responsible for message flow control; it ensuresthat a long message that is divided into several shorter messages arrives atits destination in the right order.

The Application layer is responsible for message generation, reception,and execution. The Application layer uses an end-to-end acknowledg-ment service to determine that a message sent to another node isreceived and executed, and that any required result is returned. TheApplication layer contains the CAL language parser and interpreter, andthe interface to the products application “element”—the applicationhardware or software that operates the product.

The Language

EIA-600.80 describes the Common Application Language (CAL). CALis an element, or part, of the Application layer, but because thedescription of CAL is rather lengthy, it is given its own separate vol-ume. The CAL specification defines the message structure, syntax,and data structure necessary to model and control any consumerproduct operation.

The description of CAL is divided into two separate parts. Part 1defines the message structure, syntax, and capabilities of the language.Part 2 defines the major data structures, called Contexts, that definespecific functions of consumer products. The most general Contextsare supplied as part of EIA-600. The remaining industry-specific Con-texts (HVAC, security, lighting, and so on) are published as separate doc-uments available from the CEBus Industry Council. See Chapter 7 formore information on Context documents.


The Design ConstraintsThe difficulties of designing a residential network that can be installedby a homeowner are immense. To make the task practical, design con-straints were imposed on the standard that bounded the difficulties.The scope of the network capability must be adequate to ensure success-ful consumer operation, yet be low cost and simply implemented. Thefollowing 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 productsare usually purchased one at a time, brought home, installed by thehomeowner, configured in some way, and expected to work. Nonetwork engineer is employed by the family. It cannot be knownin advance what products will be installed or the order ofinstallation. Dealers or custom home installation specialists may beused when a home automation system or a home theater is beinginstalled, but the standard is developed as though these services arenot available. The requirement to have products work correctlywithout the assistance of a specialist is still a concern of theInteroperability Working Group of the CEBus committee and the CIC.

CEBus products may be installed by knowledgeable installerssuch as the companies that install security systems, heating and airconditioning equipment, or custom entertainment equipment.These avenues of installation are an important part of the earlymarket usage, and in the installation of products requiring morethan plug-and-play skills. However, the standard must be able tosupport 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 homeowneris not a network engineer. The network must be installable andusable by anyone in the home. Even if the original installation wasdone or assisted by a trained specialist, products will be added bythe homeowner.

There is no preconceived network. It is not possible to know whatwiring is available in the home or what medium will be used forinstalled CEBus devices. Provisions must be made to allow anymedium in the home that meets the standard to be used.

19

20 Chapter 2

CEBus is primarily a residential network. CEBus is a home networkstandard, designed to handle typical residential consumer productsand systems, using the media available in the home. Specificcommercial requirements (large size, harsh environments, and thelike) were not considered. While CEBus is certainly capable ofbeing used in commercial environments—and is being used inoffices and malls—it was designed primarily for the needs ofresidential products.

CEBus must be fast enough to handle existing residential tasks. Networkmessage delays must be kept to a minimum, typically less than 0.1second. This is considered the longest time delay allowable fromthe 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 getthrough faster than noncritical messages. Yet, no one device candominate the network. All CEBus devices must be guaranteednetwork access.

Network “troubleshooting” will be difficult. Network troubleshooting—regardless of the network—is always difficult. If the networkdevelops trouble, if CEBus products fail, or if the network isdamaged, it will be almost impossible for the homeowner todetermine the fault without the assistance of extra equipment,diagnostic tools, or outside help. For this reason, high reliability andfault tolerance are part of the design criteria.

Security IssuesThe security of any network (residential, commercial, or industrial) isalways a concern, particularly as more people acquire technology allow-ing easy network access. While CEBus networks are limited in scope toone house or apartment, there is concern over possible access to the net-work from outside “malicious” users, as well as from in-home “hackers.”The concern is valid because several users of the network—such as elec-tric utilities, telephone, and cable companies—may pass rate and usagecharge information over the network.

The standard does not attempt to protect the network from inten-tional malicious access. It is possible for someone or some device to“jam” one or more of the medium networks in a home, preventing any


message communication. However, this is true of any existing hometechnology, such as security systems (particulary RF systems), telephone,cable TV, and the like.

The standard provides a compromise between the need for highsecurity and the requirements for low-cost implementation. While accessto the network is difficult to control, an optional software technique isspecified in the standard to allow devices to employ a combination ofmessage authentication and/or message encryption. Message authentica-tion requires both the sender and receiver of a message to possess a setof security “keys.” The message is readable, but the authentication algo-rithm prevents an unauthorized user from generating the same or simi-lar message. Message encryption can also be employed, using the sameset of keys, to prevent the message from being read. Both authenticationand encryption are optional security features, and only devices thatabsolutely need the level of security provided by the techniques (electricmeters, cable TV boxes) need to implement the extra software.

21


The CEBus Benefit3CHAPTER 3


24 Chapter Three

When I explain CEBus to those not familiar with the technology, or tothe press, I usually get the question: “But what does a toaster say to a tele-vision?” 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 any-thing? The answer is twofold:

1. The toaster—or thermostat, hot tub, VCR—can rely on theresources or features of the TV without having to have theseresources built into the toaster.

2. The toaster can do more. Once the toaster has access to otherproducts, it can use the features of those products “for free.” Itmay announce that the toast is ready over the intercom; it mayoperate only when the coffee pot is finished brewing; or it maysound a security alarm if the toast burns. This extra capabilitycan be achieved for a small incremental cost and enable thetoaster to command a higher market price.1 The extra capabilitycan also provide excellent marketplace differentiation, particularlyin a mature market in which there is little to distinguish onetoaster from another, except price.

The Benefits of NetworkedProductsHistorically, all consumer products, even computers, were designed to operate as stand-alone products. Everything that a product needed tooperate—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—allresources—had to be contained in the product. There was no way to dis-tribute the needed parts between products. Today, almost all consumerproducts are still designed this way. Although entertainment products(TVs, VCRs, stereo receivers) are intended to operate together, they have to

1There seems to be a common misconception among consumer product makers (particu-larly audio/video equipment makers) that consumers will not pay for additional productfeatures. The companies that believe this must not have any experience with the computerindustry.

The CEBus Benefit

be physically interconnected with a rats nest of specialized wire and arelimited to exchanging audio and video signals.

Computer products also began as stand-alone products. The personalcomputer industry started with essentially a series of custom computers.Each computer used a different operating system, a different hardwarestructure (processor, bus), and peripheral devices were, for the most part,made specifically for each individual computer. Each computer neededeverything necessary to provide all the functions it could do: compute,store, print, and display. Today, of course, almost all computer productsnetwork together. Interoperation of computer products made by differ-ent manufacturers is the rule rather than the exception. Once the net-working trend started in the late 1980s, and once users realized its bene-fits, manufacturers quickly adopted network interfaces for theirproducts. The same will happen to the rest of consumer products,including TVs, thermostats, hot water heaters, and toasters. Ten yearsfrom now, only the most trivial of products will operate as stand-aloneproducts. The benefits of networking are too compelling.

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

Control Messages

The concept of allowing one product to control another is relativelyeasy to comprehend. Many products already allow the consumer, to alimited extent, to remotely control other products. An infrared remotecontrol and the garage door opener are typical examples of one productcontrolling another. Many people enjoy the benefits of the X-10 line ofproducts that allow light switches to be remotely located from the lightsthey control. CEBus allows any product to acquire the capability to con-trol the operation of any other CEBus-compliant product. This has oneimmediate benefit to product manufacturers: it allows multiple productoperation to be centralized and performed through a common user

25

26 Chapter Three

interface. Typical examples of two products that can take immediateadvantage of this benefit are the TV and home computer. Both productsprovide a potentially simple user interface for other products in thehome 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 ofthe home, such as the time, temperature, occupancy state, and status ofequipment. The capability to share information allows

Redundant product functions to be centralized in one product

The removal of the cumbersome user interface from manyproducts

An easy delivery method for outside service information

Products simply “place” the information on the network, such as theoutside temperature, and the information is picked up by productsthat can use the information to their advantage. Again, the informationcan originate in the home, or from service providers outside the home.One of the first examples of this feature is the delivery of electric rateinformation by the electric utilities. CEBus products such as electricwater heaters, dryers, and other high-energy-consuming appliances canreceive the rate information off the network and delay operation untilrates are lower.

Typical CEBus ApplicationsThe ability to network products provides a market opportunity for awhole new category of products: resource providers. These products donothing by themselves; they are like plug-in cards for PCs. They willprovide common information or services to other products on the net-work, or a common hardware or software resource.

The simplest of these products will provide a basic piece of informa-tion 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 sim-plest, yet most useful, service providers. This little device, the same size

The CEBus Benefit

and shape as a small wall-mounted power supply, simply broadcasts thedate and time to any device in the house that needs it. It contains anaccurate clock circuit and a backup battery. The advantages of having acommon time broadcast should be obvious. Networked products nolonger need to have a clock circuit that flashes 12:00 because no oneremembers how to set it. There are many more examples of devices thatcan provide useful network information.

A simple outside temperature sensor that broadcasts the outsidetemperature to products such as a thermostat, a heat pumpcompressor, exhaust fan, or television.

A CEBus-compliant electric meter that provides the currentelectric rate (as well as future rates), the energy used this month(in kilowatt hours), and the current kilowatts being used by thehouse. This information can be used by high-energy-consumingappliances such as an electric water heater, pool heater, heatpump, or other appliances that may defer operation until ratesare lower or total house demand is lower (to avoid peak usagecharges).

Chapter 7 describes how products can easily receive any of this networkinformation without requiring any special product configuration wheninstalled.

There are also many examples of products that provide resources forother products to use. The most useful of these is the video interfacedevice, more commonly referred to as a TV. A television provides a con-venient and potentially easy user interface for the operation of otherproducts that cannot afford to incorporate a good user interface. Athermostat, particularly a programmable thermostat, needs only occa-sional attention to set or adjust heating schedules, but usually has apoor user interface (a liquid crystal numeric display and a few crypticbuttons). A CEBus-compliant thermostat can allow a CEBus-compliantTV to act as its user interface, providing easy-to-read onscreen menusand instructions.

The personal computer is the second most popular user interfacedevice in a growing percentage of homes. While it may not be as conve-nient (at least for a few more years) as a TV, its user interface capability ismore advanced. As more consumers become comfortable with usinghome computers, its role as a common user interface for home controland management will increase significantly. Computer manufacturersare already building CEBus interface circuitry into their PCs.

27

28 Chapter Three

The Future PotentialAs more networked product resources and information become availablein the home, a market develops for more complex applications. Forexample, one of the most difficult yet most useful pieces of informationto obtain about a home is whether it is occupied. This information canoften be inferred from a security system if the system is armed in an“away” mode. Many homeowners, however, either don’t use their securitysystem or forget to arm it when they leave. Knowing whether the houseis occupied must be inferred from a more complex heuristic. Havingaccess to information about the operation of the house available off thenetwork can allow a product to build probability tables about deviceactivity (lights, security devices, even plumbing). A lack of activity, whenthere is a high probability that there should be activity, may indicatethat the house is unoccupied (or that the occupants need medical assis-tance). 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 tobe unoccupied—is easy to obtain. Safeguards can be built into the prod-uct to test whether a house is unoccupied (by announcing the housestate, placing messages on TVs, and the like) to ensure higher reliability.Even if the occupancy state is calculated accurately 98 percent of thetime, the benefits are potentially terrific. As long as no serious action istaken (alerting the police, turning on or off critical appliances), beingwrong 2 percent of the time is a minor inconvenience. If a device knowsthe home is unoccupied, it can provide a valuable resource. It can armthe security system, turn off appliances, set back temperatures, turn off(or on) lights, and, in general, look after things. This may seem far-fetched, but prototypes of this function have been used with good suc-cess in home automation systems. The difference is that the homeautomation system had to be purchased and installed as a system andcost tens of thousands of dollars. In a CEBus environment, this capabili-ty could be purchased for a few hundred dollars at Circuit City andinstalled by the homeowner.

The occupancy calculator is typical of higher level products thatmake inferences from the information available on the network. Thereare many other possible applications given a critical mass of networkresources.

Fault or malfunction detector. This device looks for fault conditionsfrom products on the network (many CEBus products are capableof reporting fault conditions), for example, a malfunctioning

The CEBus Benefit

device such as a smoke detector, or a network problem such as twoproducts with the same address. It then reports the problem to thehomeowner via the TV, printer, or by voice synthesis.

Emergency “watch dog.” This is a variation of the occupancy statedevice. 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 toalert a remote family member or a medical service.

Network configuration devices. This hardware or software producthelps installation and configuration of CEBus-compliant devicesusing a rich user interface. This application typically runs on a PCand keeps a database of CEBus context use, installed products, andthe features of all networked devices. This product also allows thehomeowner to configure interproduct scenarios (described in thenext section).

The Plug-n-Play ConceptFor most of the applications described in this chapter to become a reali-ty and easily installed at low cost, it is essential that CEBus-compliantproducts be plug-n-play whenever possible. The concept of plug-n-play(the contraction of plug-and-play) is basic to a consumer-oriented net-work technology such as CEBus. Plug-and-play design allows products toaccess and use information in other products in a uniform way. It allowsone product to control another class of product without programmingor custom installation tasks. CEBus has the potential to achieve plug-n-play compatibility between a large number of products if the standardis used correctly. The benefits are substantial, but a clear understandingof what the plug-n-play concept means is essential.

Plug-n-play implies a level of interoperability that is difficult to achievein a typical network. Interoperability means the ability of products towork together over a network using a predefined level of interactionbuilt into the protocol. Protocol interoperability is a requirement forachieving plug-n-play products.

The term interoperability is often misused because the concept ofworking together, like plug-n-play, means different things to different peo-ple, particularly between manufacturers, developers, and consumers. If aproduct claims to be interoperable with other products on a network,does that mean that the product knows how to operate other products on

29

30 Chapter Three

the network? How much can it operate? What features are available?What product information is available? Can it tell whether anotherproduct is on the network?

For CEBus consumer plug-n-play products, interoperability is a pri-mary requirement; thus, it is important to clearly understand what itmeans. This means understanding how CEBus networks will be builtby consumers. The CEBus Committee assumed that CEBus-compliantproducts will be purchased, brought home, plugged in, and work. Prod-ucts are purchased incrementally, in any order, and added to over time asnew products replace older, nonnetworked, products. This networkgrowth model requires a very high level of product interoperabilitybecause it does not rely on any type of central control, or on an installa-tion expert (human or machine). To ensure this level of interoperability,all aspects of product interoperation must be defined. This includeseverything from connectors, wire, signaling, and product language, tohow products share information. This explains the need for the level ofdetail present in the CEBus standard document.

Interoperability DefinedBecause product interoperability is so important to successful use ofCEBus, it is important to clearly understand what interoperabilitymeans and how it applies at different stages of product development,installation, and use. CEBus product interoperability can be divided intothree levels: communications interoperability, applications interoperabili-ty, and scenario interoperability.

Communications-Level Interoperability

Communications-level interoperability refers to the capability of prod-ucts to send and receive packets over the network and successfullyunderstand the content of those packets. This requires that all CEBus-compliant products adhere to a proper implementation of the basicCEBus protocol design, including the physical layer and the use of thecommunicating medium. This level of interoperability is built into theprotocol code and into the product network hardware interface.

Products must use the protocol to access the attached medium, trans-mit and receive packets on the medium without interfering with other

The CEBus Benefit

devices on the network, and interpret the contexts of the packet success-fully. Products must also understand a minimum set of CAL messages.The minimum set includes commands for resource allocation and con-figuration, as well as commands to access basic information about theproduct, such as its network address, serial number, and product class.

This level of interoperability is fundamental to the technology andadherence is an absolute requirement. The guideline for ensuring com-munications interoperability is ANSI/EIA-600 where these requirementsare clearly defined. Interoperability can only be obtained if the standardis implemented correctly. While this level of interoperability is critical, itis the easiest to test. A product can be subjected to a standardized seriesof packet reception and transmission tests to ensure that packet format,timing, and protocol usage adheres to the specifications. The CEBusConformance Specifications (EIA-633) can be used by a manufacturer toensure that its product meets the minimum protocol requirements forcertification.

Application-Level Interoperability

Application-level interoperability defines how products know to use(control and share resources and information with) other devices on thenetwork, and is the basis for plug-n-play product design. This is the levelthat the consumer is most concerned about and where real benefits areachieved.

Understandably, this is the most difficult level of interoperability toachieve for two reasons:

1. It requires detailed agreements on the definition of productoperation—an area that has previously been the exclusive domainof the manufacturer.

2. It is difficult to test.

The basic CEBus tool for insuring application interoperability is theCAL language and its associated context data structure definitions. Con-texts establish a standardized data structure for each and every con-sumer product function. A product implements those contexts thatdefine all of the functions the product is capable of supporting viaCEBus. The syntax and operation of the CAL language are defined inEIA-600. The actual context data structures that pertain to real productfunctionality are defined in separate documents (grouped by industryfunctional category, such as lighting, audio/video, security, and HVAC).

31

32 Chapter Three

These documents are developed jointly by the CEBus Industry Counciland working groups of representatives from companies in each productcategory. Contexts are designed to be extended as new product func-tions emerge in each product category.

Contexts define how products are “seen” over the network. By readingand writing to variables in the context data structure, a product can beused by another device on the network. The definition for each productfunction is standardized so that, for example, the audio amplifier func-tion in a stereo receiver is operated in the same way as the audio amplifi-er function in an intercom or PC.

Contexts are designed to allow predefined pairing or “binding” of thecontexts in one device with the contexts in another device. The conceptis similar to the way hardware functions are distributed over a computerbus. The data output of a device has a predefined context destination inone device or a group of devices. The model also allows devices to broad-cast information on the network for use by any other device that canuse the information. To receive the information (such as the current elec-tric rate, temperature, or time), a device need only instantiate a copy ofthe context that receives the information. For example, consider the fol-lowing situation in which two devices are completely interoperable asfar as correct implementation of their Context data structures, yet, theydo not communicate:

An HVAC equipment vendor makes a temperature-sensing device that pro-vides the current temperature to any device that asks (reads the IV con-taining the temperature). A different HVAC manufacturer makes a ther-mostat for use with a remote temperature sensor. This device assumesthe temperature sensor will announce its temperature (send a message toa receiving context) each time the temperature changes.

Because the thermostat never asks, and the temperature sensor neverannounces, the two devices do not operate together even though theyboth use CEBus communications layers properly and both agree on howto represent the temperature in CAL. This problem can be avoided bycareful planning and development of the context models.

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

The CEBus Benefit

Scenario-level Interoperability

Scenario-level interoperability defines how two or more products useCEBus application-level capabilities to cooperate to perform a predefinedset of actions in the home. The action is usually initiated by an eventsuch 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 CEBus-networked products:

When a homeowner returns home and disarms the securitysystem, the heating temperature is set to 72°, the hot-tub turns onto 102°F, the curtains open in the living room and family room,the TV turns on to CNN, the telephone answering machine is setto answer on the eighth ring (instead of the first ring), and the PCretrieves any waiting email.

The utility company sends a broadcast message to all devicescontaining the appropriate context to receive the current priceschedule. When electric rates exceed a predetermined value, the hottub turns off, nonessential lights turn off, the air conditioning isset 3° higher, the hot water temperature is set 10° lower, and thepool pump stops circulating. When rates drop to previous levels,the process is reversed.

Unlike basic application-level interoperability, these scenarios requireagreement on the order in which messages are given and on whichdevices are the senders and which are the receivers of messages. Because adevice must be separately programmed to send and receive a specific setof messages, agreement on this subject is important.

This kind of interoperability may appear to be unmanageable. How-ever, to some degree, agreements can be achieved on the relative roles ofsensing and controlling devices and related system behaviors. Theseagreements can provide manufacturers with guidelines to achieve inter-operability relating to scenarios. The CIC works to achieve these agree-ments through a consensus of member companies.

33


CEBus Basics4CHAPTER 4


36 Chapter 4

This chapter provides an overview of how CEBus works and intro-duces the basic concepts and terminology that are used in the remain-der of the book. Most of the material in this chapter is discussed inmore detail in the next three chapters on the physical media, protocol,and CAL.

How CEBus Works—An OverviewCEBus-compliant products work by momentarily “connecting” to anoth-er product on the network to perform a sense or control operation. This“virtual connection” is achieved by gaining exclusive use of the mediumthat connects the two products long enough to transmit a command orrequest. After communication is complete, the transmitting devicesrelease the use of the medium. The medium can be the power-linewiring, twisted-pair cable, coaxial cable, RF, or IR. The messages aretransmitted by either placing a signal on the wire, or transmitting anRF or IR carrier. Messages are short, lasting an average of 25 ms, and con-tain 50 to 300 bits. By keeping messages short, many devices can share themedium without conflict because messages between any two productsare relatively infrequent.

To ensure high message delivery reliability, and to ensure that prod-ucts do not all transmit at the same time, CEBus devices adhere to astrict message protocol. A protocol is a set of rules that define how andwhen messages are sent, how to recover from transmission errors, theformat of messages, and so on. The messages contain commands in acommon command language (CAL) that is understood by each product.The command language is specifically designed for information shar-ing and control of residential consumer products. CEBus-compliantproducts are required to understand a minimum subset of the com-mand language and that portion of the language specific to their prod-uct category.

The CEBus Product ModelThis section describes the basic assumptions about the design and oper-ation of a CEBus-compliant product.

CEBus Basics

Nodes

Any CEBus-compliant device attached to a medium is referred to as aCEBus 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 ofnetwork management commands plus commands that are specific tothe device category. For example, a CEBus light switch must understandthe commands to turn on and off the light, but does not need to under-stand a command to “turn to channel 13.”

All CEBus nodes consist of the three major parts shown in Figure4.1. This diagram represents a simple internal model of every node.The parts can be implemented using any combination of hardware orsoftware.

The PROTOCOL is the same in each CEBus-compliant device and isresponsible for reliable message delivery. The protocol software definesthe 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 transmittingmessages on each medium.

The CAL portion of the model is responsible for converting productapplication events into a CAL language message—or “words”—that otherCEBus nodes understand. Likewise, it interprets received messages andaffects product operation.

37

Figure 4.1Simple CEBus productmodel.

38 Chapter 4

The APPLICATION represents the specific node application for theproduct, and contains the hardware and software that define the prod-uct operation.

Figure 4.2 shows the model in terms of the formal protocol layers thatdefine node operation. The protocol software consists of four layers orsubfunctions: the Physical layer, the Data Link layer, the Network layer,and the Application layer. The CAL interpreter is formally part of theApplication layer. A Message Transport sublayer, also part of the Applica-tion layer, provides many of the services traditionally found in a proto-col Session and Transport layer. Figure 4.2 highlights the major tasks per-formed in each layer.

Figure 4.3 shows the model in block diagram form. The I/O and applica-tion routines handle the interface of the device hardware and applicationsoftware to the Context data structure and the protocol routines. TheApplication reads and writes the context data structure to reflect prod-

Product Application

APPLICATION LAYER

MESSAGE TRANSPORT SUBLAYER

NETWORK LAYER

DATA LINK LAYER

PHYSICAL LAYER

CAL interpreterContext data structure

Message authentication/encryptionEnd-to-end acknowledged service

Intermedia routingSegmented service/flow control

CSMA protocolError detection, retransmissionDL acknowledged service

Medium interfaceSymbol timing/encodingSuperior/inferior state generation

Medium

Figure 4.2Product model interms of the protocollayers.

CEBus Basics

uct operation. The context data structures serve as the interface fromthe CEBus network to the product resources.

The application can generate messages by writing to the Context datastructure, or by forming a message “manually” and passing it to the Mes-sage Transport sublayer (responsible for receiving and generating mes-sages). The Context data structure represents a software model of theproduct’s operation to the rest of the network. The CAL interpreter trans-lates changes in the context data structure to an appropriate message toanother node. Received messages are interpreted and the context datastructure is updated accordingly.

Formally, the CAL interpreter and its associated Context datastructures are part of the protocol stack—the Application layer—butconsidering the interpreter as the protocol application is convenientbecause its function is unique to CEBus. The CEBus standard andthis book treat the CEBus protocol as the Physical layer through theMessage Transport sublayer. The protocol is covered in detail inChapter 6. CAL is treated as the CEBus application and is covered inChapter 7.

39

Figure 4.3Block diagram formof product modelshowing division ofProtocol, CAL, andApplication.

40 Chapter 4

Network Communications Models

Every communications protocol makes assumptions about the hierarchyof device-to-device communications in terms of network access controland device control. To gain a better insight into the design of the CEBusprotocol 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 medi-um to communicate (send and receive messages) with any other node inthe home. There is no communication hierarchy or restrictions on prod-uct-to-product communications over any media. This communicationsmodel is essential if CEBus-compatible products are to be installed in thehome incrementally. As devices are added to the network, they must beable to communicate with any existing products. There can be no assump-tions about the order or the type of devices added to the network.

The communications model also assumes that there is only oneCEBus medium shared by all nodes. Though many physical media typesare used (twisted-pair, coaxial cable, RF, and the like), they are treated as asingle medium, and any message generated by any node will arrive at allother nodes on the medium. The various physical media are intercon-nected by Routers and Brouters, which are described in more detail inChapter 5. The job of Routers and Brouters is to make the differentmedia behave as one medium to the connected nodes.

CEBus uses a connectionless service protocol. This means that devicesgain access to the network media only long enough to transmit a mes-sage and then get off. Because messages are short, many devices can share

Figure 4.4CEBus communica-tions model. Eachproduct communi-cates on a peer-to-peer level with allother products. Thereis no communica-tions hierarchy.

CEBus Basics

the medium. No connection is formed between two communicatingdevices and the network is not tied up during their “conversation.” Thisis different from a typical connected service network such as the tele-phone network in which two nodes establish a communication connec-tion and retain exclusive use of the media until all conversation is com-plete, then hang up, releasing the network resources for another call.

Network Control Model

The protocol supports two control models (Figure 4.5). A control modeldefines which nodes can control other nodes on the network. TheCEBus protocol assumes a peer-to-peer distributed control model, allowingany node to control any other node. This is also a result of CEBus net-works being built incrementally and in random order. Any product cancontrol any other product in the home, if it is capable of doing so.

No type of central control device or automation system is necessaryin CEBus. The absence of central control was a development goal of thestandard. Products may be added anytime by the homeowner withouthaving to notify or program a central system.

While CEBus is not dependent on central control, it does not excludeit, or the most common variation, the cluster control model. Cluster con-trol allows one or more nodes to assume the task of controlling severalother nodes. This model is employed for system-oriented products in thehome, such as HVAC systems, security systems, and lighting control sys-tems, and it is the model used by these systems for control by people. Toset the temperature in the downstairs air conditioning zone to 69°F, auser might use an onscreen menu on the living room television. Thetelevision would send a message to the downstairs thermostat requestinga new temperature. The thermostat, in turn, would send the necessarycontrol (over TP) to the HVAC air handling unit, compressor, motors, and

41

Figure 4.5CEBus control model.CEBus allows combi-nations of distributedand cluster control.Product clusters areassumed to be con-trolled by one node.

42 Chapter 4

so on, required to achieve 69°F. The television could send messagesdirectly to the HVAC air handler, compressor, motors, and so on, but itwould not know what to tell these devices; it does not contain anyHVAC system control algorithms. Telling the thermostat is easier and letsthe thermostat keep track of the HVAC system. The same control sce-nario applies to the lighting control and security systems. The necessarysystem-control software is contained in one easy-to-use node.

CEBus Reference Architecture andMediaThe CEBus standard establishes a set of Physical layer medium specifica-tions to handle all the data communications needs of the home (audio,video, computer data, and so forth). It defines the use of the power-linewiring (PL), radio frequency (RF), and infrared (IR), and the installationand use of twisted-pair (TP) and coaxial (CX) cable. Figure 4.6 illustratesthe reference architecture, or topology, for all media supported by CEBusas well as the interconnection of the media in the home and to outsideservice providers.

Figure 4.6 illustrates all of the medium support components thatmight be used in a typical residential environment for CEBus messagecommunications, as well as maximum utilization of internally andexternally supplied wideband services. The standard is flexible enough,however, to allow the use of CEBus products in existing homes usingthe PL, RF, IR, and a majority of existing TP wiring with a minimum ofadditional components. Power-line-based products, for example, requirea minimum of infrastructure support. There is no initial “network” topurchase and install. As products are purchased that utilize more of thecapability of the media, additional infrastructure support componentscan be added incrementally.

All media support components are collectively known as Node 0. Theterm Node 0 refers to all the physical components necessary to supportthe various medium networks. Node 0 consists of all Routers, Brouters,Data Bridges, and the TP, CX, and PL support hardware necessary for agiven installation. The TP network requires a power supply and a distri-bution/termination device. The CX network requires a distributiondevice containing block conversion, amplification, and control-channelregeneration functions.

CEBus Basics

Routers connect CEBus messages between two of the wired media(PL, TP, CX). Brouters connect CEBus messages between RF or IR and awired media. Data Bridges connect any audio, video, or other widebandsignals between media.

The TP network architecture is based on TIA-570 (Residential andLight Commercial Premise Wiring standard). Branch runs of four-pairjacketed cable originate at the distribution device and run to each roomwhere they connect to one or more outlets. Two of the pairs are used forexternal services, two are reserved for CEBus communications.

43

Figure 4.6 Reference media topology for CEBus networks. Media are interconnected by Routers andBrouters.

44 Chapter 4

The CX network consists of a pair of RG-6 cables that originate at the dis-tribution device and run to each room where they split to one to four dualoutlets. 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 ser-vice provider, provide the interface between the electrical characteristicsof the external network and the electrical characteristics of the CEBusnetwork. A NIU may interface any external network medium (coax,twisted-pair, RF) to any CEBus medium.

ChannelsThe CEBus standard defines two types of communication channelsavailable on each CEBus medium (Figure 4.7): a required control channelfor device message communication, and a set of optional data channelsfor distribution of audio, video, or any wideband signals.

The control channel is used on every medium to transmit and receiveCAL messages. The control channel uses a frequency spectrum on eachmedium that is always available and completely defined by a fixed fre-quency allocation, amplitude, and encoding method. The control chan-nel is required by all CEBus-compliant products to send and receive mes-sages between nodes.

Data channels are a reserved frequency space available on some mediathat may be used by CEBus devices equipped to send and/or receive ana-log or digital data. The data may be any information (music, computer

CONTROL Channel

DATA Channel (optional)

•CEBus packets

•Voice•Music (analog, digital)•Video (analog, digital)•Data files

1 0 0 0 0 0 01 1 1 1 1 1 1

Figure 4.7Each CEBus media iscapable of support-ing a Control Chan-nel and one or moreData Channels.

CEBus Basics

files, compressed video, voice) as long as it is confined to the frequencyand amplitude specified for the medium used. Data channels are cur-rently available on TP and CX, although the standard allows data chan-nels on all media. A VCR that sends its video output to an upstairs TVover the coaxial medium is a typical example of data channel use. TheVCR and TV use the control channel—exchanging resource allocationmessages—to establish the connection, and the data channels are used tosend the video, freeing the control channel for other tasks while the datatransfer continues on the data channels.

Figure 4.8 illustrates the allocation of the frequency space on one ofthe two CX coaxial cables. The control channel is assigned the frequencyspace between 4.5 and 5.5 MHz. This frequency space is reserved fordevices attached to CX for sending and receiving messages. The figurealso shows the frequency allocation of the predefined data channels.The frequency space from 54 to 150 MHz is used for transmission ofdata on one or more 1.5 MHz channels. These channels are block con-verted in Node 0 to the 324 to 420 MHz range for reception by any CXnode. The use of data channels is always optional.

Access to the data channels is independent from access to the controlchannel. A product that uses data channels will have a separate transceiv-er (potentially frequency agile) to send and receive digital or analog data(Figure 4.9).

There are two major differences between the control and the datachannels.

1. While CEBus messages on the control channel are sent andreceived in packets that are completely defined by the CEBusprotocol, the format and content of the data channels are open. Amanufacturer can use data channels to send any data that can betransmitted in the frequency allocations and amplitude availablefor the channel or channels used.

45

Figure 4.8Example of datachannel use on CX.

46 Chapter 4

2. As described in the section on the CEBus communicationsmodel, the control channel is used for connectionless serviceonly. Devices wait until the control channel is not being used,transmit a message, and relinquish control of the channel. Thisservice is required because there is only one control channelshared by all devices. Each data channel, however, is used forconnected service. Devices negotiate for the use of one or moredata channels (using messages on the control channel) dependingon the bandwidth required for the data to be transmitted. If noother node is using the requested channel(s), the requestingdevice can use the channel(s) as long as necessary to transmit thedata. To transmit a computer data file, the connection might lastfor several seconds. In the example of the VCR transmitting tothe upstairs TV, the channel might be in use for several hours.There are usually multiple data channels available on eachmedium so that several devices (64 in the case of CX) can haveaccess simultaneously.

Additional (non-CEBus) frequency space may be available on eachmedium for use by outside service providers (cable companies, tele-phone companies, and the like) who share the same medium. Thisallows products to have access to outside services as well as CEBus con-trol and data channels on the same medium. For example, productssuch as set-top boxes can access cable company-supplied program mate-rial and control messages (pay-per-view video, utility company rates,database access), and CEBus data and control channels all on the samecoax cable pair. The frequency allocation of each CEBus medium isdescribed in Chapter 5.

Figure 4.9Each CEBus nodemust have access tothe control channel.It may also accessone or more datachannels. The trans-ceiver electronics foreach channel mayshare the same cou-pling componentsand connector.

CEBus Basics

Packets and MessagesInformation is transmitted over the control channel in packets of data atabout 10,000 bits per second (bps) (regardless of the medium used). Pack-ets contain the necessary “housekeeping” information, such as theaddress of the originator and destination node, as well as the message (theCAL commands directed to the destination node). A simple analogy canbe made between the information contained in a CEBus packet and theinformation in a typical letter (see Figure 4.10).

The message contains the packet “payload” as a CAL message or replythat a node wishes to send. The message is typically 4 to 10 bytes—onlyabout one-fourth to one-half of the packet length. The addresses and ser-vice bytes make up the remainder of the packet.

For a letter (message) to reach its intended receiver successfully, the let-ter is sent in an envelope (packet), and the envelope is addressed to areceiver (the TO address). To inform the receiver of the address of thesender (or to allow the letter to be successfully returned if it could notbe delivered), the return address (the FROM address) is included on theenvelope. Each CEBus product has its own unique address, acquired

47

PACKET

AIRMAIL

CERTIFIE

D

Message

CEBus Packet

pre-amble

Data Linkservices

TO Address FROM addressNetworkservices

Applicationservices CAL message FCS

Figure 4.10 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 adevice or node address that is unique to the product. When sending let-ters, the envelope can indicate one or more post office services, such ascertified mail, next day delivery, or return receipt requested. Packets con-tain similar information.

The Data Link services (handled by the Data Link layer) determinenetwork access priority, and, thus, delivery priority, as well as a“return receipt requested” acknowledged service.

The Network services (handled by the Network layer) determinepacket routing through the network.

The Application services (handled by the Application layer)determine whether a reply is requested from the receiver andmessage security. Message authentication can be requested in theApplication services to prevent unauthorized users from accessingor changing information in some products. For example, theelectric rate information stored in a CEBus electric meter can beread and changed by the electric utility because it has the correctauthentication keys, but the information cannot be changed bynonutility devices that do not have the keys.

The Preamble and Frame Check Sequence (FCS) shown at the front andend of the packet in Figure 4.10 are fields used by the Data Link layerprotocol. The packet preamble, the first byte of the packet, is used fortransmission collision detection. The FCS is used for received bit errordetection.

Symbol Encoding

When a CEBus device sends a packet, the data in the packet is convertedfrom internal binary form to physical medium symbols. CEBus uses aset of four medium symbols, rather than the more common binarysymbols 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

Using four symbols instead of the usual two makes transmission andreception of packets easier. It allows an inexpensive and easy data com-pression technique, which is described in Chapter 6.

All CEBus nodes encode symbols by generating one of two physicalmedium states. The two states are defined as the SUPERIOR state and theINFERIOR state. These terms generically define two electrical conditionsof the medium that are easily detected by a receiving node. The statenames imply that the SUPERIOR state can always override or be detectedover the INFERIOR state. The idle state of the medium—the state whenno packets are being transmitted—is always the INFERIOR state. EachCEBus medium uses different electrical conditions, appropriate to themedium, to represent the two states. Typical representations of the SUPE-RIOR and INFERIOR state on each medium are shown in Figure 4.11.

The four symbols are encoded on each medium by using the timethat the INFERIOR or SUPERIOR state remains on the media, notwhether the INFERIOR or SUPERIOR state is used. The time is mea-sured from the transition between states. The 1 symbol is representedby the shortest interval of either the SUPERIOR or INFERIOR state (100s); the 0 is twice the interval of the 1; the EOF is three intervals; and the

49

Figure 4.11Typical symbolencoding showingthe four symbols andsymbol times. Thetransition timebetween states deter-mines the symbol.

50 Chapter 4

EOP is four intervals. Note that any symbol can be represented by eithera SUPERIOR or INFERIOR state. The end of one symbol and the startof the next occurs at the transition from one state to another. Therefore,states alternate between SUPERIOR and INFERIOR for each new trans-mitted symbol in a packet. Because the idle state of the medium isalways the INFERIOR state, the first symbol transmitted in a packet isalways encoded with the SUPERIOR state. The packet can end in eitherstate. The symbol time for the shortest symbol (1) is defined as the UnitSymbol Time (UST) and represents the minimum SUPERIOR or INFERI-OR period. The UST is the basic unit of measure for timing in the pro-tocol software.

The packet data rate is the same for all CEBus media and is stated as10,000 “one-bits” per second, because a packet containing all “1” symbolswould transmit all symbols at 100 s, or 10,000 bps. In practice, becauseeach packet contains a mix of the four symbols, the actual data ratevaries with each packet, averaging about 8,500 bps. Compression tech-niques are used in the protocol to reduce the use of zeros where possible.

The signaling technology used on each medium is tailored for thelowest cost implementation while providing the highest reliability. PLtransceivers use a novel 100- to 400-kHz spread spectrum carrier technol-ogy developed by the Intellon Corporation. TP transceivers use a simple10-kHz, 250-mV carrier; CX transceivers use an equally simple 4.5- to 5.5-MHz carrier; and IR uses a 100-kHz, 850- to 1000-nM carrier. RF uses adigitally synthesized spread spectrum carrier centered at 915 MHz.

Network Attributes

The symbol-encoding technique used in CEBus allows a uniform packetdata rate and encoding on all media in the home. All nodes, regardlessof the medium used, transmit packets using the same data rate, the samemedia states (SUPERIOR/INFERIOR), the same protocol (CSMA/CDCR,which are described in Chapter 5), and the same packet format. Thisallows packets transmitted on one medium to be routed to anothermedium with a minimum of conversion. The only difference is the elec-trical representation of the SUPERIOR and INFERIOR states in eachmedium. A product that uses the power line can be adapted to usetwisted-pair by changing only the Physical layer transceiver electronics.All other parts of the interface and node software remain the same. Thismakes the job of Routers and Brouters much easier because they onlyneed to convert media states.

CEBus Basics

CAL: What CEBus Products Say toEach OtherThe message portion of each packet contains the CAL command. CALprovides a common language interface so that products know how tocommunicate with other products without knowing how each specificproduct 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 towork together in the home—there must be some predefined model ofhow products operate and a common set of commands to perform theoperations. 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 toknow how to change the channel on any CEBus-compliant TV regard-less of manufacturer, and without having to consult with the manufac-turer. 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 appli-ances and products in the home have a hierarchical structure of com-mon parts or functions, and the basic operation of the common func-tions is the same from product to product. CAL treats each product as acollection of one or more of these common parts called Contexts.

A CEBus TV, for example, appears as a collection of Contexts at a net-work address as in Figure 4.12. A typical TV might consist of a video dis-play Context, an audio amplifier Context, a tuner Context, a clock Con-text, a user interface Context, and so on, depending on the features ofthe model. CAL defines more than 50 different Contexts for everythingfrom lighting, security, heating/air conditioning, to washing and drying.

Each Context, regardless of what product it is in, operates the sameway. The audio amplifier in the TV, in the stereo receiver, in the speakerphone, and in the intercom all work alike and “look” alike to the net-work.

Each Context consists of one or more objects. An object is a softwaremodel of a well-defined control or sensing task. Objects model the wayContext functions are normally performed manually. The volume, bass,and treble analog control objects and the mute binary switch object rep-

51

52 Chapter 4

resent controls typically found in audio amplifiers. CAL uses 26 prede-fined objects to model all control functions required for all known con-sumer/residential products. Objects, in turn, are defined by a set ofinstance variables (IVs). IVs are like variables in any software program, hav-ing a size and a data type. All network operations on Contexts are per-formed by reading and writing object IVs. The IVs that define eachobject are listed in the object tables in the CAL specification. Figure 4.13is a representation of a typical object table.

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

Figure 4.13Sample object tablefor an analog controlobject (object class08). The object oper-ation is defined by itsnine variables.

The Media andPhysical Layers

5CHAPTER 5


54 Chapter Five

In order for products to be successfully installed in the home, the specifi-cations of the media used to make CEBus networks must be completelydefined. Medium specifications allow manufacturers to make devicesthat they know can be installed in any home if the required mediumhas been installed correctly. For example, to use the power line to com-municate, a manufacturer must at least know its electrical characteristics,the carrier signaling, data rate, and so on. On media such as TP and CX, amanufacturer must also know such things as the type of connector andcable to use. All aspects of physical interoperability must be defined.

This chapter discusses the physical and electrical requirements ofeach 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 TopologyA network topology defines how nodes are connected to each other overthe network medium. The topology defines how the medium or mediaare interconnected, the path from node to node over the medium, androuting of messages over the medium.

A network (singular) implies a single uniform transmission pathinterconnecting all CEBus devices in the home. The job of making plug-and-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, telephonewiring, coaxial cable, RF, and the like, requires a clear specification ofhow the media must be used, connected to, and interconnected. To sim-plify the task, the CEBus committee made some basic assumptionsabout the specified media, the minimum media requirements, andmedia interconnection.

The first assumption was the basic medium reference architecturedesign described in Chapter 4 and shown here in Figure 5.1. This

The Media and Physical Layers

architecture defines the supported media and how the media are con-nected for the supported communications channels.

The second assumption, which can be seen in Figure 5.1, is that themedium architecture forms a tree topology. A tree topology means thatthere 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 anyother leaf. A tree topology also means that there is only one route fromany medium to any other medium. This model allows all nodes to treatthe several media that make up the network as though they were onemedium and removes the burden of message routing from the nodes.

The third assumption is that the tree is formed from the individualmedia by a set of Routers and Brouters. They handle the job of messagerouting and medium interconnection to ensure that a tree network ismaintained.

Node 0

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

55

Figure 5.1CEBus referencearchitecture.

56 Chapter Five

Node 0 collectively consists of all Routers, Brouters, Data Bridges, plusthe TP, CX, and PL support hardware. The TP network requires a powersupply and a distribution/termination device. The CX network requiresa distribution device containing block conversion, amplification, andcontrol-channel regeneration functions.

The term Node 0 originated in the mid-1980s when some members ofthe CEBus committee thought that all support hardware for all net-works (Routers, distribution devices, and so on) would be built into a sin-gle piece of hardware, purchased by the homeowner, and plugged intothe power line, a TP outlet, and a CX outlet. This hardware would bethe first CEBus component installed in the home, and would, therefore,be called Node 0. The concept that all necessary support hardwarewould be contained in a single device has long been abandoned, but theterminology stuck.1 Now any component built for network support iscalled a Node 0 device. There is a separate section in EIA-600 devoted tothe various hardware interface requirements of Node 0.

Router and Brouter Requirements

Routers and Brouters comprise one of the components of Node 0. Theyare the devices that “glue” the individual medium networks together toform 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 wiredmedium to the control channel of another wired medium. A Routermay 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 itsconnected medium are retransmitted on the other connected medium.Its primary function is to make sure that the control channel of all thewired media are connected together so that nodes do not have to knowwhat medium other nodes use. A packet transmitted on PL will windup on the medium used by the destination node.

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


Routers build an internal address directory of what node addresses areon the side of the network that they route to. This allows a more efficientpacket-routing technique. Packets are only routed to another medium ifthe destination address is on that “side” of the network (that is, if thenode 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-compliantdevice in the home that contains a Router. For example, a television maycontain a Router that connects between the PL and CX media (becausea CEBus-compliant TV connects to both). A purchased CEBus-compliantVCR—perhaps from a different manufacturer—may also contain a PL toCX Router because it connects to both media as well (see Figure 5.2).

This violates the tree topology because a packet that originates on PLwill be routed to CX by both Routers—the one in the TV and the onein the VCR. To prevent this condition, one Router must disconnect orstop routing.

To maintain a tree topology, regardless of the type, location, and num-ber of Routers installed between the wired medium networks, Routershave their own Router protocol. Routers exchange messages betweenthemselves to determine which Routers should remain on-line andwhich must disconnect.

The technique is best described by example. Assume, as shown in Fig-ure 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 allwired media.

Now assume that another device (Figure 5.4) is added to the networkthat contains a CX to TP Router (perhaps a DSS receiver). This Routerdestroys the tree topology. Packets that originate on CX will be routeddirectly to TP by the CX-TP Router, and indirectly to TP by first beingrouted to PL by the PL-CX Router, and then to TP by the PL-TP Router.

57

Figure 5.2Multiple Routersbetween two mediamay exist becauseproducts that con-nect between thetwo media may haveinternal Routers.

58 Chapter Five

This generates two copies of the same packet on TP. The problem isavoided by having one of the Routers stop routing. This is accomplishedby communication between Routers. Every few seconds, each connectedRouter transmits what is called a HELLO packet on both of its attachedmedia simultaneously. A HELLO packet is addressed only to Routers andcontains information for Routers to use for configuration.

Assume, in our example, that the PL-CX Router transmits a HELLOpacket first (Figure 5.5). The packet is picked up by the PL-TP Routerfrom PL, and by the CX-TP Router from CX. By chance, the PL-TPRouter routes the message to TP before the CX-TP Router. The CX-TPRouter picks up the message from TP. When the Router detects the samepacket (that originated from the same Router) on both media, it deter-mines it is forming a loop, and disconnects (that is, it stops routing). TheCX-TP Router continues to receive packets from both media, but it doesnot forward packets. As long as the loop condition continues, it remainsoff-line. If another Router is disconnected (for example, the PL-TPRouter), it will go back on-line again and begin routing.

Brouters Brouter is an abbreviation of Bridging Router. Brouters arelike Routers except that they route packets between nonwired and thewired 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 reli-able reception and transmission of RF throughout the house (like aportable phone). The range of an RF Brouter is typically 100 feet. Thismeans that one RF Brouter is usually sufficient for a typical home, butmore than one may be installed.

The need to maintain a tree topology is also true of Brouters, but thetechnique used to prevent multiple packets is different. More than oneBrouter may receive the same packet.

Figure 5.3Standard Router con-figuration betweenthe three wiredmedia.


This results in more than one packet on the wired medium whenonly one was transmitted. The additional duplicate packets must beeliminated. Brouters cannot use the same technique for self-detachmentthat Routers use because there is no guaranteed transmission path onthe nonwired side of Brouters. Because of this problem, duplicate RFpackets must be eliminated using detection techniques in the CEBusnode protocol. The technique is described in detail in the NetworkLayer Protocol section in Chapter 6.

Data Bridges A Data Channel Bridge is like a Router for the datachannels. Currently, only the wired media support data channels. If adevice originates a data channel transmission on one media, it can be puton another wired media by a Data Channel Bridge. The Bridge receivesone or more data channels on one medium and retransmits the informa-tion on another data channel on another medium. The Bridge changesthe data channel output frequency to correspond to a valid channel onthe output medium, and it can optionally change the modulation tech-nique. Data Channel Bridges can operate only one way, receiving on onemedium 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 proto-col as any node; therefore, it must use the control channel on the medium

59

Figure 5.4Router configurationafter CX-TP Router isadded.

Figure 5.5Use of the Router pro-tocol to resolve multi-ple Router conflicts.

60 Chapter Five

it transmits on to determine whether the desired data channel is avail-able, 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 theformation of three different sub- and supertopologies as a result of howhomes are wired: the medium network, the system network, and theglobal network.

A medium network (Figure 5.6) consists of all nodes connected to onephysical medium, such as the PL or TP medium.

The size of the network is determined by the physical size of themedium. In the case of the TP and CX medium, the medium network iscontained within one house or apartment. The PL medium network,however, extends to multiple houses and apartments because the physi-cal wiring extends beyond the walls of the home.

The system network (Figure 5.7) consists of all nodes on the networkthat share a common system address. The system network is a logical

Figure 5.6A medium network.

Figure 5.7The system networkcontains all nodeswith the same systemaddress on all media.


division with all the nodes connected by all the media, regardless ofphysical house location, to a particular home.

All CEBus nodes have a unique address pair: a system address and anode address. The system address is the same for all nodes in a house orapartment, while each node address—in a given system address—is unique.The purpose of the system address is to logically isolate the nodes in onehouse from the nodes in another house, particularly on medium networksthat span multiple houses (PL, RF). Messages addressed to a node in one sys-tem address cannot be received by nodes in another system address.

The global network (Figure 5.8) consists of all nodes that can communi-cate or hear each others’ packets.

The best examples occur on the PL and RF medium network. ThePL medium networks in adjacent homes are interconnected, forminga global network. For example, the packets transmitted by PL nodesin my house can be heard by nodes on the PL network in my neigh-bor’s house. The same is true of RF. The RF transmissions in myhouse can be expected to be heard by RF nodes in my neighbor’shouse. All the nodes that can hear each other form a global networkfor that medium.

Connection to the Outside World

The connection from the CEBus medium architecture to a Wide AreaNetwork (WAN) such as the Internet, is through one or more NetworkInterface Units (NIUs). WAN services include twisted-pair telephone ser-vice, cable service, ISDN, cable telephone service, high-speed Internetaccess, and the like. An NIU performs at least two functions:

It terminates the electrical characteristics of the external mediumand translates, if necessary, to the local electrical characteristics. For

61

Figure 5.8The global networkconsists of all nodesthat are able to com-municate.

62 Chapter Five

example, it may connect between an external fiber-optic networkand the house power line.

It translates external signaling techniques and message formats toCEBus packets on CEBus media (and possibly from CEBus to anexternal format as well). For example, it may receive RF high-speedmessages from an external cable network and translate them tostandard CEBus packets on the house TP network.

An NIU may be strictly used for data channels, control channels, orboth. It may be part of Node 0 or connect to a medium like any othernode. As long as it provides the necessary interface and isolation func-tion, there are no other specific requirements.

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

Power-Line Topology

Power-line wiring in the home consists of a series of wiring branches (car-rying 120 volts AC) from a central circuit breaker (Figure 5.9). Several out-lets connect to each branch, enough to average less than 15 to 20 amps fortypical appliances. The breaker box is connected to a “service entrance”cable consisting of three wires, called L1, L2, and Neutral. There is 120volts between L1 and Neutral, and between L2 and Neutral. There is 240volts 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 isconnected to a local distribution transformer (located on a concrete pad


or on a pole) that steps the high voltage power company feed down to240 volts for distribution to neighborhood houses or an apartmentbuilding. As many as ten houses (or twenty apartments) may connect inparallel to the same distribution transformer.

All power-line wiring from the distribution transformer, including allbranches in all attached houses, comprise the PL medium network. Aphysical connection exists between the outlets in any house with theoutlets in all other houses connected to the same distribution trans-former. This connection provides a signal path for all CEBus devices con-nected to the PL medium network.

Figure 5.10 shows how the network appears to each node. Thisschematic shows that, as far as the PL wiring from the distribution trans-former is concerned, there are no houses. Each 120-volt CEBus PL device

63

Figure 5.9 Physical representation of a typical PL network from a distribution transformer. There are typically 5to 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 itis plugged into. Every 240-volt CEBus PL device transmits packets on L1-L2. The network is large, and the loads are constantly changing. CEBusdevices are also constantly being connected and disconnected. Thismeans that the signal attenuation of the wiring and noise induced byappliances, such as motors and switching power supplies, is constantlychanging as well.

Packets transmitted in one house (or apartment) may travel to allother houses on the PL medium network. To prevent device interfer-ence between homes, CEBus creates system networks in each houseusing the system address partition. The system address logically isolatesthe nodes in one house from the nodes in another house. The addressconfiguration 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 aspread-spectrum signaling technology for the control channel. Spread-spectrum signaling works by spreading a transmitted carrier over arange of frequencies rather than using a single frequency. The CEBus PLcarrier is spread over the range of 100 to 400 kHz during each bit in thepacket. Unlike traditional spread-spectrum techniques that use frequen-cy-hopping or direct-sequence spreading, the CEBus PL carrier sweeps

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

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


through a range of frequencies as it is transmitted. A typical spread-spec-trum waveform, representing the CEBus “1” bit, is shown in Figure 5.11.

The waveform is synthesized from a table of 360 digitized valuesgiven in the standard. The points were chosen to maximize in-bandenergy while keeping harmonic out-of-band content to a minimum.Notice that the waveform frequency starts at 200 kHz and sweeps to 400kHz, jumps to 100 kHz, and then sweeps to 200 kHz. The phase transi-tion from 400 to 100 kHz was kept within the body of the waveform tobetter control the abrupt transition. The complete 200–400/100–200kHz frequency sweep (called a chirp) takes 25 cycles in 100 s.

Bandpass of Chirp The odd shape of the spread-spectrum carrierwaveform is due to several technical and FCC requirements, and resultsin the frequency spectrum shown in Figure 5.12.

The energy of the chirp is concentrated in the band of frequenciesbetween 100 and 400 kHz. The amplitude of any out-of-band energy above400 kHz must be less than 1 mV to not only meet FCC conducted emis-sion limits, but to ensure that packets on PL will not cause interferencewith inexpensive AM radios attached to the same wiring. The amplitudeof any out-of-band energy below 100 kHz must be less than 5 mV. Thislevel also meets FCC limits and prevents potential interference with ser-vices such as LORAN.3 By literally hand “tweaking” the waveform, the bandedges are fine-tuned to achieve a high degree of out-of-band attenuationwhile allowing up to 7 volts peak within the band. Filtering is stillrequired to and from a PL transceiver, but is minimized by the wave shape.

65

Figure 5.12 Fre-quency spectrum ofthe PL spread-spec-trum waveform.

100 kHz 400 kHz

1 mV5 mV

7.0 V

PL carrier spectrum

3LORAN operates at 100 kHz throughout the United States and provides air and marineradio navigation.

66 Chapter Five

Encoding States The waveform in Figure 5.11 represents the SUPERI-OR state. Because it lasts for 100 s, it is a SUPERIOR 1. The 0, EOF, andEOP symbols are formed by repeating the waveform every 100 s. TheINFERIOR state is represented differently during different parts of thepackets. During the Preamble (the first byte of the packet), the INFERI-OR state is represented by the absence of a spread-spectrum carrier—thenormal form of the CEBus INFERIOR state. During the informationportion of the packet (everything except the Preamble), the INFERIORstate is represented by the inverse SUPERIOR state; that is, the SUPERI-OR state chirp is inverted 180° as shown in Figure 5.13.

The “normal” SUPERIOR state is called the SUPERIOR Ø1. The INFE-RIOR state is referred to as the SUPERIOR Ø2 state (the phase inversionof SUPERIOR Ø1). The INFERIOR state is represented by the SUPERI-OR Ø2 because it is necessary to have the carrier on at all times duringthe information portion of the packet to keep the receiver “locked” onto(to correlate and track) each Unit Symbol Time (UST) in the packet andto still be able to use the INFERIOR/SUPERIOR distinction to representsymbols. This greatly enhances received signal reliability. The INFERI-OR state is represented by the absence of a signal during the Preambleto 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.13The SUPERIOR Ø1waveform and theINFERIOR state ver-sion of the waveform,the SUPERIOR Ø2waveform.


during the INFERIOR state (the absence of a carrier) to detect a collisionwith another transmitting node.

A spread spectrum receiver works by recognizing the pattern of thereceived signal. It compares, or correlates, the received signal pattern withan internal representation of the pattern. If enough of the received pat-tern matches, the signal is detected. After the received signal pattern isinitially matched, the receiver “locks on” to the carrier and its detectionjob becomes easier, because each following symbol must occur at regu-lar 100 s intervals. It may take several USTs of carrier for the receiver tomatch the incoming spread-spectrum waveform correctly, but oncelocked to the waveform, symbol detection is robust.

Packet Encoding

Figure 5.14 shows part of a typical PL packet. A packet starts with a Pre-amble consisting of a pseudorandom pattern of eight 1 or 0 symbols fol-lowed (on PL and RF only) by a Preamble EOF symbol consisting ofeight SUPERIOR 1 symbols. The first symbol of the Preamble alwaysstarts in the SUPERIOR state. The Preamble EOF is followed by theinformation portion of the packet. A small portion of the Preamble andthe information portion of the packet are shown in Figure 5.14. Noticethat during the Preamble, the SUPERIOR state is represented by thepresence of a carrier (the SUPERIOR Ø1 state), and the INFERIOR stateis 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 ver-sions of the carrier is on at all times. The timing of the states during thePreamble is slightly different. This timing difference allows easier detec-tion of the Preamble, especially during noisy conditions, and prevents

67

Figure 5.14Portion of a PL packetshowing two sym-bols of the Preambleand two symbols ofthe rest of the packet.

68 Chapter Five

the receiver from mistaking the Preamble for the information portionof the message if a collision occurs during the Preamble.

The advantage of the spread-spectrum signaling used by CEBus isthat it can overcome the two worst PL signaling problems: attenuationof a band of frequencies by certain electrical loads, and noise generatedby dimmers, motors, and the like. The CEBus spread-spectrum carriercan tolerate attenuation and noise over many frequencies as long asenough of the signal gets through to the receiver. Because spread-spec-trum receivers work by recognizing the pattern of the waveform andbecause they are relatively insensitive to the amplitude, the signal canwithstand attenuation and noise that destroys nearly half the waveformand still be recognized by the receiver. This makes CEBus PL signalinghighly reliable.

Physical Layer Implementation

The PL physical layer is responsible for generating and detecting thepresence of INFERIOR (both types) and SUPERIOR states on the PLmedium. Figure 5.15 illustrates the typical components of the powerline physical layer.

The CELinx IC is a CEBus spread-spectrum symbol generator/detec-tor. 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 isbandpass filtered, amplified, and coupled to the AC line. The bandpassfilter provides additional out-of-band attenuation. The coupling net-work consists of a toroid impedance-matching transformer and a 60-Hzblocking capacitor. Coupling is between Neutral and L1 or L2. Protec-tion should also be provided for high-voltage AC transients coupledfrom the power line.

Figure 5.15PL physical layer com-ponents for a typicalpower-line interface.


The output network (amplifier, filter, coupling components), needs toprovide an output signal between 100 and 400 kHz at a signal level onthe power line of between 2.5 volts and 7.0 volts peak-peak into animpedance of 10 to 2 k. Power-line impedances vary greatly over thisfrequency range.

The localized, lumped impedance of the power-line wiring in ahome over the 100 to 400 kHz frequency range will vary from a low of0.8 to 20 or more depending on the appliances connected to the net-work. Most of the attenuation experienced on the PL comes fromattached devices, but because the power-line wiring has a typical imped-ance in the CEBus frequency range of about 10 per 100 feet, thewiring impedance tends to isolate transceivers from severe loads if theyare far enough away.

Reception of the spread-spectrum carrier is through the same cou-pling network as the transmitter and a receive bandpass filter. The band-pass filter reduces out-of-band received noise and prevents front-endoverload. The receiver must be capable of detecting symbols correctlywith a received signal amplitude of 0.5 mV to 7.0 volts while in the pres-ence of impulse and continuous noise. This represents about a 65-dBreceived signal dynamic range.

Figure 5.16 is a block diagram of a typical PL spread-spectrum IC. Thereceived signal is amplified, A/D converted, and fed to the heart ofthe chip, the matched transversal filter. The filter provides correlation of the received signal with an internal template of the SUPERIOR Ø1and SUPERIOR Ø2 waveform. The magnitude of the correlation isdirectly related to the quality of the received chirp. The state of the cor-relation (SUPERIOR Ø1 or Ø2) is determined by the phase of the chirp.Once the filter has begun to track the incoming data, it will maintaintracking with only marginal signals for over 1 ms before indicating a

69

Figure 5.16Block diagram of typi-cal PL transceiver IC.This example is basedon the CELinx IC fromIntellon Corp.

70 Chapter Five

loss. The filter outputs an indication of a match with either waveform. Thedigital logic uses symbol-detection indication timing from the filter tocompute received symbols and pass them to the attached Data Link layer.

Transmitted symbols are fed to the output waveform generator. Thewaveform generator consists of three parts: a ROMed wavetable, a D/Aconverter, and an output amplifier. The 360-point wavetable contains thebinary image of the output chirp. An address generator clocks throughthe complete table for each chirp transmitted. Either the “true” or invertedversion of the wavetable data is output to a 6-bit D/A, depending on theSUPERIOR phase required.

The IC also contains the CRC computation logic. As the packet istransmitted, the CRC logic computes a 16-bit CRC. When the EOP is received and transmitted by the chip, the 16-bit CRCs are appended tothe packet. As a packet is being received, and the end of the Preamble isdetected, the CRC logic does the same calculation on the received bits ofthe information part of the packet. When the EOP is received, theremaining 16 bits are internally stored and compared with the calculat-ed 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 typi-cal residential PL network is very good. Packets are typically deliverederror free well over 98 percent on the first try. With the packet retrymechanisms built into the Data Link layer (described in Chapter 6), mes-sage delivery can approach 100 percent. However, no PL signaling tech-nology is perfect and conditions can exist in a home that will severelyinterfere or completely block transmission. The problems—caused byother appliances that connect to the power line—fall into two categories:devices that generate power-line “noise,” and devices that absorb power-line signals. Devices that generate noise include broadband “blasters”such as wireless intercoms, baby monitors, and PL music distributiondevices. The music distribution system is the worst. These devices trans-mit the output of stereo receivers or CD players to remote speakersplugged into the power line. The interference from these devices isworse when they are located near a CEBus PL receiver.

Devices that absorb power-line signals are becoming more trouble-some with the increasing popularity of PCs in the home and theaccompanying proliferation of surge protectors. PCs limit the noise


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

The TP NetworkThe TP Physical Layer of the CEBus standard is based on the Telecom-munication Industry Association (TIA) residential telephone wiringstandard (ANSI/TIA/EIA-570A). TIA-570A is a residential telephonepremise wiring standard that describes how new homes should bewired for high-quality telephone service. In the home, the standardspecifies that a four-pair twisted and jacketed cable be run from a cen-tral location—or distribution point—to outlets in each room. Incom-ing telephone service is connected at the distribution device to eachbranch cable.

CEBus builds on TIA-570 to include all the requirements necessary totransmit control and data channels on the same cable. The added CEBusrequirements include the addition of a power supply to one of the pairs,and defining proper lengths and termination necessary to support thesignal 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 speci-fied in TIA/EIA-570A: four twisted, unshielded, jacketed pairs. This typeof cable is referred to as UTP (unshielded twisted-pair) and is shown inFigure 5.17.

71

72 Chapter Five

Note that the TIA-570A specification specifies the use of Category 3rated cable or better, while the CEBus specification is intended to useany twisted-pair cable rated Level 2 or better. TP cable ratings aredescribed in ANSI/TIA/EIA-568 and TIA TSB-67.

Each pair in the cable is color coded. The cable must use 22 or 24 AWGsolid conductors with a maximum resistance of 29 per 1,000 feet. Thecable 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

Figure 5.17TP cable uses fourtwisted-pairs labeledTP0, TP1, TP2, andTP3. Each pair uses acolored wire with awhite stripe, and awhite wire (whichmay have a smallstripe of the samecolor).


TP Cable Specifications (Continued)


Characteristic Impedance

at 1 kHz: 500 700

at 1 MHz: 85 115

These specifications allow the four-pair twisted cable alreadyinstalled in many homes to be used for control and data channel trans-mission. This minimum specification will give acceptable results withbasic (Level 2) four-pair twisted cable with the length restrictions speci-fied in the standard.

Wire Color The pair coloring specified in the CEBus standard isbased on the standard TIA-570A pair coloring and given in the follow-ing table.

TP Pair Coloring Specifications

TIA Pair CEBus Designation Pair Color

Pair 4 TP0 BrownWhite/Brown

Pair 3 TP1 GreenWhite/Green

Pair 2 TP2 OrangeWhite/Orange

Pair 1 TP3 BlueWhite/Blue

Wire Pair Use Table 5.1 shows how each wire pair is used by theCEBus standard. Wire pairs are named TP0, TP1, TP2, and TP3. TP0 isused for the control channel and data channels. TP1, TP2, and TP3 areoptionally used for data channels only. The use of data channels on TPis entirely optional and can be used only if the cable is dedicated toCEBus use.

The selection of the wire pairs for CEBus is intended to allow easycoexistence with other services likely to be used on TP cable, including

73

74 Chapter Five

voice, ASDL, Ethernet, and so on. It does not conflict with the newerHomePNA technology (that uses Pair 1—the blue pair).

TP0 can also be used to distribute 18 volts DC to power low-voltageattached devices. The table shows the assignment of the control channeland data channels to each pair.

TP Control Channel

The TP control channel is a 10-kHz square wave transmitted at base-band on TP0 in a reserved frequency band from 0 to 128 kHz. Theremainder 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 chan-nels (each channel is 32 kHz wide).

Figure 5.18 illustrates the control channel encoding. The control chan-nel uses a low-voltage 10-kHz differential signal superimposed on thepower supply voltage to encode the SUPERIOR and INFERIOR states. ASUPERIOR state is represented by the presence of either a positive ornegative differential voltage relative to the average DC supply voltage pre-sent on the TP0.

The encoding waveform can be thought of as the output of a 10-kHz square-wave generator, gated on and off in multiples of 100 s torepresent the symbols. Gating the square wave on for 100 µs (one-halfcycle of the 10-kHz waveform) represents a SUPERIOR 1 symbol.Removing the waveform for 100 µs represents an INFERIOR 1. Noticethat the SUPERIOR state waveform must be generated in such a waythat there are an equal number, on average, of positive and negativehalf-cycles. This prevents TP control channel transmitters from induc-ing a DC bias. The voltage amplitude of the SUPERIOR state can varybetween ±150 to 600 mV. The absence of a differential voltage (zero volts

TPO Brown/White 18V Control Data Ch.White DC Channel 4-32

TP1 Green/White Data Ch.White 32-63

TP2 Orange/White Data Ch.White 64-95

TP3 Blue/White Data Ch. White 96-128

TABLE 5.1

TP cable-pairusage showingcontrol and datachannel assign-ments to eachpair.


with respect to the DC level) represents the INFERIOR state. Theallowed output voltage variation for the control-channel waveformmakes it relatively easy to meet a wide impedance variation by using asimple current drive output stage.

TP Physical Layer

The TP physical layer requirements can be met in a number of ways. Nospecific TP transceiver ICs were available at the time this book was writ-ten. The TP physical layer can be implemented using existing ICs or dis-crete components. The basic transceiver requirements are shown in Figure5.19. The control channel transmitter must be able to deliver a differentialbaseband signal in the range of 150 to 600 mV and be able to reliablyreceive the control-channel signal down to 25 mV. The input impedancemust be 2.5 k or more while not transmitting. Out-of-channel signalamplitudes from the control channel waveform must be less than 2.5 mVabove 128 kHz.

Figure 5.20 shows a representative control channel transceiver inmore detail. Coupling to and from TP0 is via a hybrid transformerwith windings for the receiver section and transmitter section. TheTP winding is DC blocked by a capacitor. Power is extractedthrough a bucking choke to filter control and data channel AC com-ponents and to maintain a high input impedance at frequenciesabove about 2 kHz.

75

Figure 5.18 TP control channel encoding using a grated differential square wave.

76 Chapter Five

The CX NetworkThe CEBus coaxial cable (CX) network distributes audio, video, and wide-band signal sources throughout the home. The network replaces the tradi-tional single coax cable TV wiring and provides additional capability fordistributing high data bandwidth source material. The network wasdesigned by the CEBus Committee to distribute signals reliably up to 1GHz to or from any coaxial outlet in the home. This bandwidth will han-dle any expansion of cable TV channel capacity for the foreseeable future.

The CX network, like the TP network, originates at a central locationin the home and provides branch cables to each room of the house.Unlike the TP network, CX is a true transmission—line network—eachbranch consists of a pair of coaxial cables, driven and terminated sepa-rately. One cable of the pair, the EXTERNAL cable, provides all sourcematerial (video, audio, data) from outside the home, such as cable televi-

Figure 5.19Typical control chan-nel electronics usinginductive coupling toTP0. A simple block-ing filter must beused if the deviceobtains power fromTP0. The SE sublayeris the portion of thePhysical layer thatencodes anddecodes symbols.

Internal

External

Control ChannelData Channels 1-64

Cable TVOff-air (VHF/UHF/FM)

In-home-generated video

Optional in-home-generated video

Figure 5.20CX cable pairs. TheInternal cable is bi-directional for all con-trol and in-home datachannels. The Exter-nal cable is singledirectional (unless areverse channel isused by the cablecompany).


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

The Cable

The CEBus coaxial cable specification is designed to be met by existinggood quality RG-6 (or better) cable to handle signals up to 1 GHz withminimum attenuation and minimum radiation and leakage (into andout of the cable). The cable must meet the electrical and mechanicalspecifications in the following table.

Coax Cable Specifications


Center conductor

Diameter: 0.039” 0.042”

Resistance/1000 ft: 36

Dielectric O.D. 0.175” 0.185”

Shield

% foil coverage: 100%

% braid coverage: 59%

Resistance/1000 ft: 5

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

77

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 con-ductors of common lamp cord. The two cables must use different colorPVC jackets (black and white) or be marked INTERNAL and EXTER-NAL to distinguish between the internal and external cables.

CX Network Topology

The CX network topology is shown in Figure 5.21. Cable-pair branchesoriginate at a central distribution amplifier and block converter, andbranch to a four-way cable splitter in each room. Within each room, upto four branches are run to dual cable outlets.

In-home–generated data channel sources transmit on the INTER-NAL cable. These signals are received at the amplifier/block converter,block converted to a higher frequency band, amplified, and then distrib-uted 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 fromthe 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 mustbe terminated in a 75 resistive termination.

Each branch must have one to four CX wall connectors attached tothe four-way splitter.

150' MAX

INTERNAL Cable

EXTERNAL Cable

Amp./BlockConv.

DistributionDevice

CableService

Off-airantenna Wall

connectorpair

4 w

ay S

plitt

er

4 w

ay S

plitt

er

Figure 5.21CX cable topology.Any number ofbranches can bemade from distribu-tion device if properamplification is pro-vided. Each branchcan also be “home-run,” instead of usinga splitter (recom-mended).


The maximum distance for any one branch from the Node 0distribution device to the farthest wall connector must be no morethan 150 ft.

The signal input/output specifications must be met for the Node 0distribution device to be capable of handling any number of cable-pair branches.

While the standard assumes that the outlets from any splitter are used inone room, the outlets may be placed anywhere as long as the total cablebranch from the distribution device to the outlet does not exceed thecable 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-waysplitters: one for the INTERNAL cable and one for the EXTERNAL cable.The signal attenuation inherent in the splitter is compensated for in thedistribution electronics. The splitter can be installed anywhere as long asit is accessible for service.

There is no specific location requirement for the placement of thefour-way splitter in the branch. In fact, the four-way splitter can beinside the Node 0 distribution device. This produces a slightly differentequivalent topology in which each branch cable run originates at theNode 0 distribution device and terminates at the wall connector. This isthe way most coax distribution devices on the market operate. As long asthe signal amplitude is the same from the distribution device as it is outof the splitter, the four-way splitter can be functionally integrated inthe 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 Fig-ure 5.22. The connectors are standard coax F-style screw-on feed-throughjacks. The outlet must label the INTERNAL and EXTERNAL jack.Unused jacks must be terminated in 75 resistance, either by connect-ing to an external terminator, or by using a self-terminating jack.

The standard recommends that the coax male connectors employ apush-on-and-lock mechanism to maintain connection with the femalejack, and a self-crimping mechanism over an internal mandrel to main-tain connection with the coax cable.

The standard also recommends using polarized cable connectors thatprevent a cable from being attached to the wrong outlet jack. TheEXTERNAL cable connector is polarized with two tabs set 180° apart,

79

80 Chapter Five

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 functional block diagram of the Node 0amplifier/block converter/distribution device. The diagram only showsthe general construction of the distribution device and is not meantto imply a specific implementation. Not all the items shown in the dia-gram are required.

Control-channel packets are transmitted by CX nodes on the INTER-NAL cable modulated at 5.5 MHz, and are received and combined at theINTERNAL splitter. A control channel regeneration device converts the packets to 4.5 MHz and amplifies them for distribution back oneach INTERNAL cable branch.

CX Node 0 Distribution Device Data channel signals transmittedfrom nodes on the INTERNAL cable are also received and combined atthe INTERNAL splitter. They are passed through a 54–150-MHz band-pass filter prior to the block converter. The block converter converts thereceived 54–150 MHz band to a 450–546 MHz HI band (or to a318–414 MHz LO band, selectable on the block converter). The block-converted data channels are then amplified and placed back onto theINTERNAL cable.

0.75" min.

INTERNAL

EXTERNAL

Figure 5.22CX wall plate show-ing the two requiredconnectors for INTER-NAL and EXTERNALcables. Distanceshown between con-nectors is to allowattachment of amolded dual cableconnector.


An optional output selector can place the block-converted data chan-nels onto the EXTERNAL cable if the frequency space is not in use by acable service.

The block diagram shows two sources of external video: an off-airantenna input and a cable input. One or the other can be used. Whichev-er source is selected, it is amplified and placed on the EXTERNAL cable.An optional low-frequency (5–50 MHz) return cable path is shown foruse by cable service providers that have reverse channel capability.

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

81

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

82 Chapter Five

Attached devices transmit the control channel on 5.5 MHz, and the dis-tribution device regenerates the signal back onto all attached INTER-NAL cables at 4.5 MHz.

The INTERNAL cable is used for distribution of all in-home–generat-ed video. There are sixty-four 1.5 MHz data channels available from 54MHz to 150 MHz. Standard NTSC video signals transmit on four con-tiguous data channels (6 MHz). Thus, 16 standard television channels canbe transmitted simultaneously. The data channels are block converted to450–546 MHz and amplified for redistribution back on the INTERNALcable for reception by CX devices. The data channel frequencies werechosen to enable transmitted video channels to be viewed on standardcable 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) recep-tion. The typical bandwidth used by cable companies is 54 to 450 MHzfor cable channels 2 to 69, but many cable operators furnish additionalchannels and services up to 850 MHz. Off-air VHF and UHF frequen-cies are also shown.

It is possible to place the block-converted data channels on the EXTER-NAL cable for viewing by devices that only connect to the EXTERNAL

Figure 5.24 CX frequency allocations on the EXTERNAL and INTERNAL cable.


cable. If cable service is being received and no cable signals are presentabove 450 MHz, the HI block-converted band can be placed on theEXTERNAL cable. If off-air service is being received, the LO block-con-verted band (318–414 MHz) can be placed on the EXTERNAL cable.These frequencies, however, are cable channel frequencies, and to viewthem, the receiver must tune to cable rather than off-air channels.

CX Control Channel The CX control channel transmitter uses anamplitude shift-keyed 5.5 MHz carrier. The carrier output amplitude isnominally 100 mV peak to peak. The time the carrier is on or off deter-mines the symbol. The presence of the carrier represents the SUPERIORstate, and the absence of a carrier represents the INFERIOR state. Figure5.25 shows typical encoding for a CX control channel.

The carrier is received by the control channel receiver at 4.5 MHz, hav-ing been block converted and amplified in the Node 0 distributiondevice.

CX Physical Layer

The CX physical layer can be easily implemented using discrete compo-nents. The basic transceiver requirements are shown in Figure 5.26. Thecontrol channel transmitter must deliver a nominal 100 mV of 5.5 MHzASK carrier. This can be easily implemented by gating a 5.5 MHz oscilla-tor from the symbol data stream. The receiver must recognize the carrierdown to 16 mV, and demodulate the AM back to a symbol data stream.

83

100 s"1"

100 s"1"

100 s"1"

100 s"1"

200 s"0"

200 s"0"

200 s"0"

5.5MHz

SUPERIOR

STATE

SUPERIOR

STATE

SUPERIOR

STATE

SUPERIOR

STATE

INFERIOR

STATE

INFERIOR

STATE

INFERIOR

STATE

100 mV

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

84 Chapter Five

CEBus RFCEBus RF communication uses the 902–928 MHz radio band. Thisband is just above the cellular phone band and is shared by otherlicensed and unlicensed users. This band was chosen because of thewide frequency space available for low-power unlicensed consumerdevices, and because transceiver technology for this band is widelyavailable due to the introduction of many 902–928 MHz consumerproducts.

The CEBus RF medium is similar to PL in two ways: First, it is usedby other services. The 902–928-MHz band is used by consumer unli-censed products such as portable phones, baby monitors, remote IRrepeaters, and other low-cost consumer products. It is also used by somelicensed applications such as vehicle locators and amateur radio. Second,it is not limited to a single apartment or house. Because CEBus RFdevices have a range of about 100 ft, they can easily be received byneighboring houses and apartments. Therefore, all of the potential inter-ference problems inherent in PL also exist on RF. While RF does notsuffer like PL does from attenuating devices on the medium, it does haveadditional unique problems. RF signals at frequencies as high as 900MHz are subject to relatively small metal obstructions, such as metalbuilding framing, filing cabinets, refrigerators, and similar objects, thatcan cause signal reflections and blockage. Care must be taken duringinstallation of RF devices to make sure that a usable signal path existswith other devices in the home.

CEBus RF Signaling

The CEBus RF control channel also uses a spread-spectrum signalingtechnique. While the PL spread-spectrum carrier used an analog wave-form, the RF carrier is digitally synthesized.

Figure 5.26CX Physical layertransceiver block dia-gram. Nodes transmitat 5.5 MHz andreceive at 4.5 MHz.


The control channel is generated using a 4.3- to 6.2-MHz direct-sequence spreading function to modulate a 915-MHz carrier. This resultsin a double sideband output spectrum with sidebands centered at 5.25MHz above and below the carrier frequency. The receiver can tuneeither or both sidebands. Like PL, the RF receivers are sensitive to thepattern of the received signal rather than the amplitude, and once thereceiver “locks on” to a signal, it can still receive the packet in the pres-ence 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, onehas not yet been specified for CEBus RF.

The CEBus RF specifications require that CEBus RF devices be able tocommunicate over a free space distance of 100 ft. In a home, the distancewill be reduced depending on the materials in the home and deviceplacement. While RF signals may be transmitted or received from aneighbor’s house, the different device system addresses will prevent mes-sage interference.

RF Control Channel Encoding

Like PL, the RF control channel relies on the spread-spectrum carrierbeing always on during the information portion of the packet. Thisresults in the need for two SUPERIOR states during the informationportion of the packet, the SUPERIOR Ø1 and Ø2 to represent the INFE-RIOR state.

The basic SUPERIOR Ø1 state is generated by a digital “spreadingsequence” that modulates a 915 MHz carrier. Figure 5.27 illustrates that eachSUPERIOR UST is made up of seven substates. A substate is generated froma series of 360 25.2-MHz bits that last for one-seventh of a UST and form a4.3–6.2-MHz spreading sequence. Seven substates are combined (2,520 bitsfrom seven spreading functions) to form one complete UST.

There are two different, and opposite, spreading sequences. The topsequence shown in Figure 5.27 represent the bit order of the forward-spreading sequence. The 1 and 0 bit pattern of this sequence starts, ascan be seen, from three 1s, then three 0s, then three 1s, and so on, form-ing a 4.2-MHz square wave. The bit sequence is dithered from three 1sand three 0s to a series of two 1s and two 0s (6.3 MHz) by the end of thesequence. In between, sequences of three 1s and 0s are mixed with two1s and 0s, so that there is an even frequency distribution between 4.2and 6.3 MHz. The bottom sequence in the figure is just the reverse; it

85

86 Chapter Five

spreads from 6.3 MHz to 4.2 MHz and is called the reverse-spreadingsequence.

The normal SUPERIOR state, the SUPERIOR Ø1, is formed by com-bining the spreading sequences in the order shown in Figure 5.25: for-ward, forward, forward, reverse, reverse, forward, reverse. The SUPERI-OR Ø2 UST, used to represent the INFERIOR state during theinformation portion of the packet, is formed by combining thespreading sequences in just the opposite order. The reverse patternmakes it easy for the spread-spectrum receiver to differentiate betweenthe two states.

The spreading sequence that makes up each SUPERIOR state isrepeated as many times as necessary to form each symbol (twice forzero, three times for an EOF, and four times for an EOP). During thePreamble, the INFERIOR state is represented by the absence of aspread-spectrum carrier. The absence of a carrier or signal is the nor-mal form of the CEBus INFERIOR state. During the information por-tion of the packet, the INFERIOR state is represented by the reverseSUPERIOR sequence; that is, the SUPERIOR Ø2 spreading sequence inFigure 5.25. The INFERIOR state is represented as a SUPERIOR Ø2 statebecause of the necessity of having the carrier always on during theinformation portion of the packet so as to keep the receiver “locked”

Figure 5.27RF UST encoding.Each UST consists ofone of two combina-tions of a 360-chipsequence. One com-bination forms theSUPERIOR Ø1; theother combinationforms the SUPERIORØ2.


onto the packet while still using the INFERIOR/SUPERIOR distinc-tion to represent symbols. This greatly enhances received signal relia-bility. The INFERIOR state is represented by the absence of a signalduring the Preamble to allow the Data Link layer (DLL) access proto-col to function properly. The protocol relies on the detection of a car-rier during the INFERIOR state to detect a collision with anothertransmitting node.

A spread-spectrum receiver works by recognizing the pattern of thereceived signal. It compares, or correlates, the received signal pattern withan internal representation of the pattern. If enough of the received pat-tern matches, the signal is detected. Once the received signal pattern isinitially matched, the receiver locks on and its job becomes easierbecause each following symbol must occur at regular 100 s intervals.

Figure 5.28 shows a sample of the packet waveform. During the pre-amble portion of the packet, the SUPERIOR state is represented by thepresence of the SUPERIOR Ø1 carrier spreading (although slightly mod-ified), and the INFERIOR state is represented by the absence of a carrier.During the information portion of the packet, the SUPERIOR state isrepresented by the SUPERIOR Ø1 carrier spreading and the INFERIORstate is represented by the SUPERIOR Ø2 carrier spreading. The timingof the spreading sequence during the preamble is slightly modified (thesymbol time is 114 s, and a slight delay is placed between each substate).This timing difference enables easier detection of the Preamble, especial-ly during noisy conditions, and prevents the receiver from mistaking thePreamble for the information portion of the message if a collisionoccurs during the Preamble.

RF Physical Layer

The RF physical layer is responsible for generating and detecting thepresence of INFERIOR (both types) and SUPERIOR states to and fromthe RF medium. Figure 5.29 illustrates the typical components of the RFphysical layer. This diagram is based on the CELinx RF CEBus spread-spectrum IC made by the Intellon Corporation.

The RF CELinx IC is a digital spreading-sequence symbolgenerator/detector. Symbol data is passed from the Data Link layer tothe IC (1, 0, EOF, EOP). The IC generates the necessary digital spreadingsequence for SUPERIOR Ø1 or SUPERIOR Ø2. The digital spreadingsequence is bandpass filtered and mixed with the output of a 915-MHzlocal oscillator. The outputs of the mixer (both mixing products) are

87

88 Chapter Five

amplified and coupled to an antenna. The RF output spectrum lookslike Figure 5.30. The mixer generates two 2.1-MHz sidebands, one cen-tered at 909.75 MHz, the other centered at 920.25 MHz.

The radiated output power of the transmitter depends on theantenna design and other product physical characteristics. The mini-mum power should produce a signal strength of 58 mV/meter mea-sured at 3 m. Maximum power cannot exceed the radiated power lim-its prescribed by the FCC for Part 15 operation.

The receiver section amplifies the antenna signal through a bandpassfront-end filter. The receiver can use either sideband, or it can switchbetween sidebands to avoid interference. The received signal is mixed

Figure 5.28Portion of the RFpacket showing twobits of the preambleand two bits of theinformation portionof the packet. Duringthe Preamble, the for-mation of the SUPERI-OR UST is altered toprevent false receiversynchronization.

Figure 5.29Typical RF transceiverblock diagram. Out-put of the spread-spectrum digital IC isconverted to the RFfrequencies by a 915-MHz local oscillator.


with the 915-MHz local oscillator to directly recover the spreadingsequence bitstream. This is amplified, limited, and fed to the RF CELinxIC. The IC performs state detection by correlating the received bitsequence with an internal model of the sequence; if a match occurs, itgenerates an indication to the DLL of the received symbol.

The IC also contains CRC computation logic. As the packet is trans-mitted, the CRC logic computes a 16-bit CRC. When the EOP is receivedand 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 theinformation part of the packet. When the EOP is received, the remain-ing 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.

89

2.1 MHz 2.1 MHz

909.75 MHzLSB

920.25 MHzUSB915.0 MHz

carrier centerfrequency

Figure 5.30Mixing the chip datastream with the localoscillator forms twosidebands that are10.5 MHz apart andcentered at 915 MHz.


Protocol6CHAPTER 6


92 Chapter Six

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

A Little Protocol BackgroundCEBus inherited much of its original protocol design from Homenet. Inthe early 1980s, a newly formed group at General Electric, led by JackFrancis, developed Homenet—the first communication protocol specifi-cally designed for the home. Homenet was used in GE’s HomeMinderproduct. It was the first home automation system available to the con-sumer that provided whole-house automation using low-cost two-waycommunications on the power line. Over years of review and refine-ment, many changes were made to the protocol to reflect demands forhigher speeds, greater reliability, and security, and much of the Home-net design was lost. However, the Data Link layer still retains many ofthe original Homenet concepts.

CEBus Protocol OverviewIn the early 1980s, the International Standards Organization (ISO) adopt-ed a model for open communications systems, which is known as theOpen Systems Interconnect (OSI) reference model. This model wasintended to be used in the definition of actual protocols. The protocolused by CEBus is described in EIA-600 using the OSI model.

The OSI model defines the functions and services available in anycommunications 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 bedescribed using the OSI model. Due to its wide use and acceptance, theCEBus Committee also chose this model to describe the CEBus proto-col, and the EIA-600 sections on protocol are based on the OSI formatand terminology.

Protocol

The model has several advantages. It takes all the complexity of com-munications software and divides the functions into seven predefined“layers.” For this reason, the model is often called the OSI seven-layermodel, or the OSI seven-layer protocol stack. A diagram of the stack isshown in Figure 6.1. The model defines the seven protocol functions ina hierarchical way, each layer of the model relying on the “services” ofthe layers below it. Each layer has a specified set of responsibilities and,ideally, only communicates with the layer above and below. Starting atthe Application layer, each layer below provides a more “primitive” proto-col service for the layer above. The top layer, the Application layer, corre-sponds to the application using the protocol. The lowest layer, the Physi-cal layer, corresponds to the lowest-level tasks, usually associated with thehardware necessary to transmit each bit of the data on the connectedmedium. The model is similar to the way software languages use sub-routines. Each layer “calls” the layer below to provide a more primitivefunction.

Each layer is assigned a general set of services:

The Physical layer is responsible for reliably transmitting andreceiving each bit, or symbol, on the attached medium. All issues

93

APPLICATION APPLICATION

PRESENTATION

SESSION

TRANSPORT

NETWORK

DATA LINK

PHYSICAL

NETWORK

DATA LINK

PHYSICAL

MEDIA

Ne

two

rk L

aye

r M

an

ag

em

en

t

ISO Open SystemsInterconnection

Model

CEBus Model

TRANSPORT

Figure 6.1CEBus protocolmodel vs. traditionalOSI seven-layermodel.

94 Chapter Six

dealing with mechanical and electrical implementation aredetermined at this layer, including signal levels, bit transmissiontiming, bit error detection, and maintaining proper physical andelectrical characteristics on the medium.

The Data Link layer provides reliable communications betweennodes on the same medium. The Data Link layer defines thefundamental unit of data transfer, which is often referred to as apacket 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 themedia, including collision avoidance and detection. It also performspacket error detection, packet transmission timing, addressrecognition, duplicate packet rejection, and packet transmissionfailure detection and retransmission.

The Network layer provides reliable communication across multiplemedia, including networkwide communication functions such asnetwork address management. The Network layer provides routingservices to ensure a packet arrives at the correct destination nodeon the correct medium.

The Transport layer provides end-to-end service between source anddestination nodes on the network. This is performed by requiringthe destination node to acknowledge successful message receptionand retransmission of packets that are not acknowledged. TheTransport layer also handles large message fragmentation andreassembly, and the creation and maintenance of networkconnections that are required by the Session layer.

The Session layer manages communication sessions or connections.Sessions allow nodes to establish single or bidirectional logicalconnection until all communication is complete, and thenrelinquishes the connection. This service is typically used forconnected service protocols such as time-sharing service access,telephone systems, and the like.

The Presentation layer provides any necessary translation ofapplication data into a form used for packet transmission. It isresponsible for converting transmitted and received data to a formusable by the Application layer. The Presentation layer is typicallyused to convert file formats (graphics, bitmaps, and so on) andhandle the conversion of a local format to a remote node format.This layer can also implement data compression/decompression toyield higher throughput on the network.

Protocol

The Application layer is the application using the communicationservices of the lower layers. This may be an operating system, acommunication program, telemetry software, and the like.

The OSI model is just that—a model—and no one protocol adheres toall services and layers of the model. Specific protocols use a subset—asappropriate to the communication services offered by the network—ofthe services of each layer. Specific implementations of protocols also takeliberties 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 OSImodel. CEBus implements a Physical layer, a Data Link layer, a Networklayer, and an Application layer. In addition to the protocol functionsdefined by the OSI model, the CEBus standard also defines the physicalcharacteristics of each of the allowed media. It also implements many ofthe functions of a Transport layer, but instead of establishing a separateTransport layer, the needed functions are included in the Applicationlayer and the Network layer. CEBus also defines Network layer managementfunctions of each layer and the interaction between layers. Network layermanagement includes the housekeeping functions required between lay-ers such as power-on states, error resets, and resource management.

Because CEBus is a connectionless service protocol, no Session layerfunctions are used. The Presentation layer is not necessary because thereis no requirement for conversion of data to or from a format used by theApplication (the Application in CEBus is the CAL language interpreter).

The Peer-to-Peer Layer Model

The concept of peer-to-peer node communications (introduced inChapter 4) is applicable to each protocol layer. Each protocol layer com-municates on a peer-to-peer basis with the corresponding layer of thenode it is sending to or receiving from. The concept is illustrated in Fig-ure 6.2. The task of the protocol, including the CAL interpreter, is tomake the application (the hardware) of the node behave as though it isconnected, for a short time, to the hardware in another node. The proto-col establishes this “virtual” connection by transporting the hardwarefunction from one node to another. The CAL interpreter converts the

95

96 Chapter Six

connection request into words (CAL commands), which are sent to theother node in the CAL message. The CAL interpreter in the originatingnode then communicates with the CAL interpreter in the destinationnode, which converts the words back into an action on the destinationhardware. This may result in a reply message from the destination CALinterpreter back to the originating node CAL interpreter.

The CAL interpreter in the originating node relies on the services ofthe rest of the protocol “stack” to reliably deliver the message to the CALinterpreter in the destination node. To deliver the message, the CAL inter-preter passes the message to the Application layer for delivery. The Appli-cation layer software prepends an Application layer message to the CALmessage to form an Application Protocol Data Unit (APDU). The APDUis sent to the Application layer in the destination node. The added APDUinformation informs the destination Application layer about requestedservices, such as whether the message is encoded and whether a messageacknowledgment is requested. The added bytes are called the APDUHeader and are intended for the destination Application layer to deter-mine what Application layer services are requested.

The Application layer, in turn, passes the APDU to the Network layerfor transmission. The Network layer software prepends a Network layermessage to the APDU to form the Network Protocol Data Unit (NPDU).The NPDU is sent to the Network layer in the destination node. Theprepended information is called the NPDU Header and is used by thedestination Network layer to determine what network wide services arerequested. For example, the APDU may be too large to send in one pack-et (a single APDU is limited to 31 bytes). The Network layer can segmentthe APDU into two or more messages and inform the destination Net-work layer, in the NPDU Header, how many segments are being sent.The destination Network layer reassembles the segments prior to passing

application

CAL

APPLICATION

NETWORK

DATA LINK

PHYSICAL

application

CAL

APPLICATION

NETWORK

DATA LINK

PHYSICAL

FUNCTION

CAL message

messageAPDU

NPDU

DLPDU

DLPDU

APDU

NPDU

PACKET

Figure 6.2Each layer of the pro-tocol communicatesdirectly with thesame layer in the des-tination node.

Protocol

the APDU to the Application layer. The NPDU Header information isalso used by network Routers and Brouters to determine how the packetis to be routed through the network.

The Network layer, in turn, passes the NPDU to the Data Link layerfor transmission. The Data Link layer software prepends a Data Linklayer 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 destina-tion node. The prepended information is called the DLPDU Header. TheDLPDU Header contains the destination node network address and theoriginating node address, as well as a request for one of several possibleacknowledgments from the destination node. The destination node DLLdetermines whether the destination address matches its own address andreturns any requested acknowledgment to the originating DLL to indi-cate the packet was successfully received.

The Data Link layer must gain access to the time-shared medium usinga CSMA/CDCR protocol (Carrier Sense, Multiple Access/with CollisionDetection and Collision Resolution). Once access is obtained, the DLLpasses the assembled DLPDU to the Physical layer serially, a symbol at atime, for transmission on the medium. The Physical layer converts thesymbols 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 desti-nation node may fail anywhere along the path from the originatingCAL interpreter to the destination CAL interpreter. If a failure occursin the originating node “down” the path from the application to trans-mission by the Physical layer, the requesting layers are informed of theerror by the lower layer where the failure occurred. For example, if theData Link layer was unable to transmit the message (if it was unable togain control channel access after a certain period of time), it willinform 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, informthe user, or give up).

If the failure occurs in the destination node, each destination layer isresponsible for communicating back to the corresponding originating layerthat it is unable to handle the message. For example, if the originating node

97

98 Chapter Six

Application layer requested secure services from the destination node(by indicating that the originating CAL message is encrypted), and thedestination node is not able to handle secure messages—encrypting isan optional service—then the destination node Application layer mustsend an APDU Header back to the originating Application layer. Thereturned message (an APDU reject message) will indicate that the mes-sage was rejected because the destination node could not handle securemessages. The returned packet contains only an APDU Header, no CALmessage. The originating Application layer may then inform the deviceapplication that message transmission failed at the destination node.

Application Layer vs. the Application

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

Packet Format

The CEBus packet structure (Figure 6.3) reflects the contribution of eachprotocol layer to the packet. The DLPDU, NPDU, and APDU are built bythe Data Link layer, Network layer, and Application layer respectively.The remaining non-PDU parts of the packet are the Preamble and theFrame Check Sequence (FCS). The Preamble is a random 8-bit valueprepended to the start of the packet by the Data Link layer. The Pream-ble is used during the medium access protocol to detect and resolve colli-sions between transmitting nodes. The FCS is a packet-level error-detec-tion field appended by the Data Link layer (an 8-bit checksum) or the

Protocol

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

Layer ResponsibilitiesThe rest of this chapter describes the functions and services of each pro-tocol layer. It is important for anyone using CEBus—whether you writeprotocol software, buy it, or use an IC containing it—to be familiar withthe services that the protocol provides. This is because the services mustbe requested by the device application; they are not determined automat-ically. When sending a message to another node, the application isresponsible for knowing where the message goes (the destination addressof the receiving node or nodes), as well as how to get it there (the proto-col services necessary for successful transmission). The following protocollayer sections explain the services provided by the layer well enough foryou to know where and when to use the services of that layer.

Application LayerThe CEBus Application layer is responsible for the interface with thenode application. Figure 6.4 illustrates the Application layer in more

99

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

Figure 6.3 Representation of the packet format. Each portion of the packet is contributed by one of the threelayers of the protocol.

100 Chapter Six

detail. The Application layer is made from two subparts: The CALInterpreter Element and the Message Transfer Element. The CAL Interpreter receives messages, parses them, and updates the Con-text data structure accordingly. It also generates a message for trans-mission if a reporting condition in the Context data structurerequires it. The Message Transfer Element (MT Element, or MTE)builds the APDU. It receives message transfer requests from either theCAL 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 theapplication, depending on the type of message.

The specific responsibility of each application element is shown inTables 6.1 and 6.2. The CAL Interpreter element tasks are given in Table6.1. This table indicates the tasks performed when receiving or sending amessage.

The Message Transfer Element tasks are given in Table 6.2. The tableindicates the tasks performed when receiving or sending an APDU.

The MT Element receives requests to transmit messages from eitherthe CAL Interpreter or directly from the application along with theApplication and lower protocol layer service requests. It builds theAPDU and passes it down to the Network layer along with servicerequests for the Network and other protocol layers. Upon APDU recep-tion, the MT Element parses the APDU Header from the message, per-forms the service requested in the header, and passes the message to

Figure 6.4Application layerstructure. The Appli-cation layer containsthe CAL Interpreterand the MessageTransfer Element.

Protocol

either the CAL Interpreter or to the application depending on the typeof message received, and which element originated the message in thesending node. The MT Element is responsible for two primary protocolservices offered by CEBus: end-to-end acknowledged service and authen-tication.

The APDU Header

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

Basic Service APDU

The content of the 1-byte Basic Service APDU Header is illustrated inFigure 6.5. This is the most common form of the APDU and is used forall nonsecure messages.

101

ELEMENT Sending Task Receiving Task

CAL Monitor reporting IVs Parse messages

Generate report messages Update context data structure

Generate response messages Handle error conditions

Generate error messages

TABLE 6.1

CAL Element tasks

Table 6.2

Message TransferElement tasks.


MT Build APDU Parse APDU

Handle authentication Handle authentication response requests

Handle acknowledged Handle acknowledged service timing service requests

Handle APDUretransmission

102 Chapter Six

The basic APDU consists of a 1-byte header followed by a 0- to 30-bytemessage. The header determines the Application layer services.

The Mode bit (MSB) is always a 1. It indicates the message service isCEBus. This bit may be used in the future to indicate transport ofother, non-CEBus information.

Figure 6.5Basic Service APDUheader. The first twobits (27, 26) arealways set to 1 forthis service. Theremaining contentsof the byte infer thetype of message.

Figure 6.6Extended Serviceadds authenticationto the basic APDUservices. The first twobits in the first byteare always 1,0. Theauthentication algo-rithm used deter-mines the contentsand number of theoptional authentica-tion data fields sur-rounding the CALmessage.

Protocol

The Type bit is 1 for 1-byte Basic Service APDU (0 for variable lengthExtended Service).

The APDU type is a 3-bit field indicating the type of service requested ofthe originating and destination MT Elements. The services areexplained 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 messagenumber tag to allow MT Elements to track outstanding “invoke”requests to other nodes. The invoke_ID is assigned by the originatingMTE. Any response from a destination node contains the same IDthat was used in the original request.

Extended Service APDU

The content of the multibyte Extended Service variable length APDUHeader is illustrated in Figure 6.6. Extended Service APDUs are onlyused for secure message transfer using a message authentication processwith optional encryption. The first two bytes of the header are alwayspresent. The remaining bytes (3−n) contain the CAL message and a vari-able number of authentication data bytes, depending on the authentica-tion 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 isencrypted.

The APDU type is a 5-bit field indicating the type of authentication ser-vice requested of the originating and destination MT Elements. Theservices are the same as the Basic Service APDU with the addition ofthe first two types listed (Challenge_request and Authenticate_response).

The second byte of the Header contains a 5-bit Authentication Algo-rithm ID field. This field indicates the type of authentication usedby the originating node and allows implementation of 32 differentalgorithms.

The invoke_ID field is the same 3-bit field used in the Basic ServiceAPDU.

The remaining variable number of bytes in the header are used for theCAL message and the message authentication data. The number and

103

104 Chapter Six

location of bytes used for authentication data depends on the Authenti-cation Algorithm used as indicated by the Algorithm ID. The use ofExtended Service APDU and an explanation of authentication is givenin the Security Section of this chapter.

Basic MT Delivery Services The MT Element offers several deliv-ery services to the CAL Interpreter or application. The services ensurereliable message delivery by requiring that the receiving node (ornodes) generates a response message to the sending node. The responseserves two purposes. First, it indicates that the destination nodereceived the message successfully, and second, it provides a mechanismto return result data back to the originating node. For example, if amessage is sent to a thermostat asking for the current heating setting,the value of the heating setting is returned to the sender in theresponse message.

There are four basic MTE services: implicit_invoke, explicit_invoke,conditional_invoke, and explicit_retry. The MTE Extended Services com-bine these with message authentication.

Implicit_invoke is a simple one-way service—a message is transmittedbut no response is requested. This service is typically used when amessage is broadcast to a large number of nodes using thebroadcast system address or a group address when a replay is notneeded from the receiving nodes.

Explicit_invoke, conditional_invoke, and explicit_retry services are varia-tions on the same service; however, a response from the destination nodeis requested.

Explicit_invoke service requires an end-to-end acknowledgmentfrom the destination MTE. This service is used to ensure that thedestination node receives the message and the result of themessage is returned. End-to-end means that the service operatesover the entire network regardless of the media connection ofthe communicating nodes. A result will always be returned evenif the result is just an indication that the message was executed.This service is also used when a value is read from thedestination node.

Conditional_invoke service requests a response if, and only if, thetransmitted message produces a positive result in the destinationCAL interpreter. Conditional_invoke is typically used to find whichof many nodes meet a certain criterion.

Protocol

Explicit_retry is the same as explicit_invoke with the addition of anautomatic retry service performed in the MTE. When a reply tothe APDU is not received within a fixed time interval (typically 1.5seconds), the MTE retransmits the APDU a second time.

NOTE: The use of explicit_retry service is optional and is not recom-mended because a receiving node may not support this service in itsMTE. This service is easily implemented in the application code thatoriginates the message. If a reply is not returned, the application simplyretries the message.

The remaining APDU types are returned as a result of using theabove services.

Result is the APDU type of a returned message containing a resultgenerated by an Explicit or Conditional request.

Reject is the APDU type returned when the MTE in thedestination node encounters an error condition and cannot processthe message.

Receipt_Ack is the APDU type returned when using explicit_invokeservice and the destination node is delayed in responding.

Basic Service DetailsThe following sections describe the operation of explicit_invoke, condi-tional_invoke, and explicit_retry service in enough detail for you tounderstand 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 asmall group of nodes and a response is desired from the destinationnode(s). The response indicates that the message was received and actedon. This service provides a high degree of message delivery reliabilityand is used whenever possible. This service must be used when a value isread from the destination node and a returned result is required. Thereturned message will have a Result APDU type with the sameinvoke_ID as the original explicit_invoke APDU, and a result code (alongwith any returned value) in the message portion of the APDU. The pos-sible returned results are:

105

106 Chapter Six

A result complete code (the message was executed by thedestination 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 indetail in Chapter 7.

Figure 6.7 illustrates the action of the MTE in the sending and receiv-ing node, as well as the packets generated during an explicit_invoke ser-vice request. The figure indicates the cause-and-effect actions that takeplace in each layer for each step of the message transfer. Time is indicatedvertically (that is, time passes from the top to the bottom of the figure).

The transmitting node MTE receives a request to send a message2 andbuilds 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.5-second MT Response Timer.3 This timer sets the maximum time that theMTE will wait for a response from the destination node before giving upor trying again.

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

2The MT Element can receive a request for message transmission from either the CALInterpreter or the device application. However, because requests for explicit_invoke serviceinvariably originate from the application, the application is always shown as the originatorof the message in the examples.3The minimum recommended time for a reply is 1.5 seconds. This timer can be adjustedbased on knowledge of the anticipated packet transmission time. Packets that are routed viaBrouters, or that use segmented service, will require longer roundtrip acknowledge times.

Protocol

At the destination MTE, the message is received from the Networklayer. The APDU is parsed, and the message portion is passed to CAL. Ifexplicit_invoke service is requested, the MTE starts a 100 ms MT WaitTimer. This timer sets the maximum time that the MTE will wait for aresult 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 CALresult, and transmits the APDU via the Network layer.

The originating MTE receives and parses the APDU, matches theResult 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 beunderstood. The second example, illustrated in Figure 6.8, shows whathappens if the destination node result packet is lost (or the transmittedpacket never arrived at the receiving node). If a result APDU is notreceived within 1.5 seconds, the originating nodes MT Response Timerexpires and the MTE notifies the application of the failure. It is up tothe 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 theCAL interpreter at the destination takes too long to return a result to theMTE. If generating a result takes longer than 100 ms, the MT Wait Timerexpires and the MTE sends a receipt_ack APDU back to the originating

107

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 originatingnode 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 origi-nating node from initiating a retry prematurely.

In practice, the MT Wait timer is usually not necessary. It is unlike-ly a message will require more than 100 ms processing time on thepart of the CAL interpreter because messages read or write to vari-ables that are part of the context data structure. This data shouldalways be immediately available. There may be cases, in particularimplementations, in which the processor time available to the CALinterpreter is interrupted for more than 100 ms by an application task.

The originating MTE, upon reception of the receipt_ack APDU, stopsits MT Response Timer and notifies the application. The application canthen choose to continue to wait for the result, or continue without theresult. When the result is finally received, the originating MTE passesthe result to the application.

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

Protocol

Conditional_Invoke Service Conditional_invoke service is identicalto explicit_invoke service except for the criteria used by the receivingCAL interpreter to generate a result, and the lack of a receipt_ack fromthe destination node MTE. Conditional_invoke service requests aresponse from the destination node(s), if and only if, the transmittedmessage produces a positive result by the destination CAL interpreter. Apositive result means that the CAL interpreter generates a result valuebased on the received message or performs a requested operation suc-cessfully. Any error condition or failure to perform a requested CALmethod does not generate a response. Because the destination nodeMTE does not send a receipt_ack APDU, a response APDU is only sent ifa result is generated by CAL.

Conditional_invoke service is intended to minimize result traffic, andresult processing. It is typically used when the destination address isother than a single node address; that is, where more than one node is used as the destination. This usually occurs when the destinationaddress is a group address or the broadcast address. Conditional_invokecan be used to find out which of many devices on the network meet acertain criteria.

For example, a node might transmit a message that says, “If yourproduct class is TV then return your node address.” This enables thenode to find the network address of all TVs in the house. Ifexplicit_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 outthe undesired results. If conditional_invoke service is used, only thenodes that are TVs will respond.

Explicit_Retry Service Explicit_retry service is described in the EIA-600 document. It allows the MT Element to contain an automatic retrymechanism (similar to the Data Link layer) to resend a message if anexplicit_invoke response is not received and the MT Response timerexpires. This MTE service is described in this section but the author rec-ommends that the service be implemented in the application. If aresponse is not received, simply generate a new MT message deliveryrequest. Because reception and processing of an explicit_retry APDU areoptional, it is best to avoid using the service because it may generate areject response from the receiving node.

109

4Nodes 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 anautomatic retry service performed in the source MTE. When a result mes-sage is not received from the destination node within the time interval ofthe MT Retry Timer, the MTE retransmits the APDU a second time. Theusefulness of the service is illustrated in Figure 6.10. If the original APDUis 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 ofthe retransmission is the loss of the original Result APDU from the des-tination node. This causes the original APDU to be resent. The destina-tion node, upon receiving the second explicit_retry message with thesame invoke_ID, discards the message (does not pass it to CAL), butresends 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.

Protocol

same node at a time. Before sending another message, the receiving nodemust have processed the previous message and returned a result (ifusing explicit_invoke service). However, a node can have several messagesoutstanding to different nodes. The sending node must keep track ofwhich 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 trackoutstanding invoke operations. The invoke_ID is a 3-bit number (0−7)assigned sequentially to each new explicit/conditional_invoke messagesent by the MTE (wrapping around from 7 to 0).5 The destination MTEhandling the invoking operation returns the same invoke_ID in anyResult, Reject, or receipt_ack APDU. This process allows an invokingMTE to associate incoming responses with a particular invoke. An origi-nating MTE may not use an invoke_ID that is still pending a responsefrom a remote MTE. An MTE that receives a duplicate invoke_ID fromthe same source address MTE must reject the duplicate invoke. This

111

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

5The 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 betweenthe source address of an explicit-type APDU and the invoke_ID longenough to recognize a duplicate message. The duplicate might be causedby a lost Result APDU. In fact, an association must be kept (in an associ-ation table) for each outstanding message sent to a different node address,and for each received request for an explicit service. The received mes-sage association must be kept to reject a duplicate request from the samenode. The association time should be kept for a reasonable networkdelay time after a response is returned or a duplicate response isreturned (nominally 12 seconds). The transmitted message associationmust be kept until a result message is returned successfully or until asufficient amount of time has passed for a response to have beenreceived (network round trip delay plus receiver response time). Thistime should be longer than the receiver association timer (nominally 20seconds). This will prevent the transmitter from reusing the same ID tothe same node prior to the association being discarded in the receiver.

Reject APDUs

A Reject APDU is generated by a destination node MT Element any-time the MTE is unable to process the received APDU. The resultantReject APDU contains a 1-byte code (in the CAL message position) toindicate the reason for the reject in the returned message. The codes areas 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 ofthe MTE or CAL Interpreter processing a previous APDU.

When to Use What Service

Which Application layer service to use must be determined when a mes-sage is sent to the MT Element for transmission. This means that whenthe application or the CAL Interpreter generates a message, it must fur-nish, along with the message, all the information necessary to transmit

Protocol

the message. This includes the Application layer service, the Networklayer service, and the Data Link layer service requests, as well as the desti-nation address of the message. This information exchange between theapplication and Message Transfer, and between the CAL Interpreter andMessage Transfer is shown in Figures 6.12 and 6.13 using C-like functioncalls. An implementer is free, however, to “hide” the selection of layer ser-vices in the protocol layer code by making service selections based onthe type of message or destination address.

In Figure 6.12, the application is free to generate any type of mes-sage using any type of Application layer service. The application mustknow the destination address as well as the service necessary from eachprotocol layer.

Generally, the application is the only element that originates a mes-sage that generates a result (such as requesting the current temperature,or the status of the security system) using explicit_invoke or condition-al_invoke service. The reply, from each node addressed, is returned fromMessage Transfer along with the source address (shown in the rec_replycall). The source address is necessary because it is not always the originaldestination address of the message that generates the response. The mes-sage may have been sent to the broadcast address (for example, to get thenode address of all TVs) and generated several replies.6

The CAL Interpreter is more limited. CAL can receive a message toread or write a value to its Context data structure (Figure 6.13). Theoperations can be conditional based on other values in the Contextdata structure. CAL can also generate a message (called a reportingmessage) based on a condition in an object. For example, it can send a

113

Figure 6.12Interface from theapplication code toMT code (*message isa pointer to the mes-sage to send, *replyis a pointer to thereceived message).

6This 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 anothernode, so it will know the state of the light. The message generated bythe interpreter does not generate a reply or return any result (exclud-ing any explicit_invoke acknowledgment).

When CAL generates a Reporting message, it must know the destina-tion address as well as the service necessary from each protocol layer. Thedestination address is either obtained from the received message (request-ing 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 intothe interpreter.

The rules for using the Application layer basic services by the applica-tion and the CAL Interpreter are given in Table 6.3.

When an application uses conditional_invoke service, it must beprepared to process Result messages from several nodes.

Application Layer ExtendedServicesThe Application layer Extended Services provide message security. Mes-sage security means that an unauthorized node (person, hacker, and the

Figure 6.13Interface from theCAL interpreter to MT.

Protocol

like) cannot read a message, decode it, and then possibly resend it toduplicate its results. It is intended to prevent unauthorized operation ofCEBus devices or unauthorized reading or writing of data in CEBusdevices.

Message security cannot prevent a person or a device from “jamming”the network to prevent a message from being sent or received. It is diffi-cult to prevent electrical access to the network, but relatively easy to pre-vent message traffic from being decoded.

Authentication

Authentication is an umbrella term for two types of CEBus message secu-rity: message sender authentication and message encryption. Either orboth services may be used for any message.

Authentication provides a means for a destination device to verify theauthenticity of a message originating device. This capability allows the node manufacturer to prevent selected data in the node from beingwritten (or even read) by an unauthorized node. For example, CEBus-compliant electric meters contain the current electric rate and accumu-lated electricity usage for the house. This information can be read by anode in the house, but cannot be changed without knowing theauthentication access keys to change the data. This information can beread and written by the electric utility because it possesses the currentkeys for access.

115

Service Application CAL

Implicit_invoke Use when a response is Use for message reportingnot desired, or when when transmittingtransmitting to a group or to a group or broadcast broadcast address. address.

Explicit_invoke Always use when Use for message reportingtransmitting to a when transmitting tonode address. a node address. Used

for message deliveryconfirmation only.

Conditional_invoke Use when conditionally Not used.reading a value from a group address.

Table 6.3

Rules for decidingwhich Applicationlayer service touse for messagedelivery.

116 Chapter Six

Authentication Algorithms

All secure service code is contained in the MT Element. There are twogeneral forms of authentication algorithms allowed by MTE ExtendedService: a one-way authentication algorithm, and a two-way algorithm.The one-way algorithm transmits all necessary information in theAPDU for the receiving node to verify the transmitter. The two-wayalgorithm requires a message handshake between nodes.

The goal of either algorithm is to make it impossible for someone (byreading network traffic) to determine how to duplicate the traffic ordecode the algorithm and send messages to read or alter secure nodedata. Both algorithms ensure that the message contains enough random-ness that decoding the data is extremely difficult.

Two-Way Authentication Algorithm The two-way authenticationalgorithm requires that two Authentication Keys (S1 and S2) be main-tained in each node that uses the algorithm. The keys are stored in theNode Control Object of the Universal Context. S1 and S2 must beknown by the node issuing a secure command and the node executingthe command. Both nodes must also know the same encoding algo-rithm, E. E is a predefined encoding function that accepts a key and arandom number and then produces a value.

When a destination node CAL Interpreter receives a command andthe command requires authentication, CAL instructs the MTE to issue achallenge_request APDU. The MTE generates a random number R, andthen calculates X E(S1, R), encoding R with key S1. It then sends thechallenge_request APDU with X in the Authentication Data field (start-ing at byte 3) of the APDU (see Figure 6.6). When the originating nodeMTE 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 Datafield of the authenticate_response APDU. When the destination nodereceives the authenticate_response APDU, it calculates R′ E1(S2, B). IfR′ equals the original R, then MTE informs CAL and the original com-mand is executed; otherwise, an authenticate_reject APDU is returnedwith a reject code of 33 Hex (authentication failed).

Obviously, both nodes must know both S1 and S2, and the encodingalgorithm E. How the nodes acquire S1, S2, and E is up to the manufacturer.

One-Way Authentication The one-way authentication algorithmallows authentication data to be passed in the original commandrequest. This service only requires one key, S1, and the encoding algo-

Protocol

rithm E, but both nodes must know the same random number R. Rmust be a random value that changes with time (for example, the timeof day).

When an originating node knows that a command requires authenti-cation, the application or CAL requests one of the authenticate servicesfrom the MTE. The MTE calculates X E(S1,R) and transmits theauthenticate service APDU with X in the authenticate data field fol-lowed 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 com-mand contained in the message field is passed to CAL for execution.Otherwise, an authenticate_reject APDU is returned with a reject codeof 33 Hex (authentication failed).

Both nodes must know S1, the encoding algorithm E, and how to calcu-late 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 thevalue of the current time. Because the time in both nodes should be equalover 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 authenticationdata sent in the APDU) are scrambled using a technique known to boththe 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 usedand the ENC bit in byte 1 of the Extended Service Header byte must beset. The encryption algorithm is specified using the AuthenticationAlgorithm ID field in the second byte. The field may specify an authen-tication algorithm, an encryption technique, or both.

Using Secure Services

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

117

118 Chapter Six

It is easy to get paranoid, especially in today’s scary society, about thesecurity of mundane messages and network information, such as the state of light switches. Fears of hacking a house are exaggerated. It ispossible, 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 tosteal electricity, and another to turn on someone’s bedroom lights as aprank. The latter can be done with existing technology—houses usingX-10 can be easily hacked to turn on or off lights and appliances, andsecurity systems can be easily jammed or defeated. But it just doesn’thappen. It is either too much trouble for limited results (in the case ofhacking X-10) or unnecessary (in the case of defeating security systems).

Network LayerThe Network layer is responsible for networkwide services across anymedia used in the home. The Network layer in each node communi-cates with the Network layer in other nodes, as well as with the Networklayer in Routers and Brouters.

The CEBus Network layer (NL) interfaces with the Message TransferElement of the Application layer, and the Data Link layer. The Networklayer receives requests for message transmission from the Applicationlayer and notification of received messages from the Data Link layer.The Network layer responsibilities for message transmission and recep-tion are given in Table 6.4.

The MT Element makes requests to the NL for APDU transmissionusing selected NL services. The Network layer then builds the appropri-ate NPDU Header and forms an NPDU for transmission. The Networklayer passes the NPDU to the Data Link layer with a request for requiredDLL services.


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

Table 6.4

Network layerresponsibilities

Protocol

When an NPDU is received from the Data Link layer, the NPDUHeader is parsed and the requested Network layer services are per-formed (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 withthe destination NL. It is 1 to 8 (or more) bytes long and reflects thedesired NL services requested by the originating Network layer. Figure6.14 illustrates the NL Header structure. The figure shows, on the leftside, 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 isreferenced throughout the discussion of the Network layer.

The NL Header size depends on the services requested. The first byteshown in Figure 6.14 is the NL Service byte and is the only requiredbyte in the header. It indicates, primarily, the services requested ofRouters or Brouters to get the packet to its destination. All remainingbytes are optional and exist only if a corresponding flag bit is set in theNL Service byte.

NL Service Byte This section describes the structure and function ofeach bit field of the NL Service byte.

The most significant bit (MSB) of the NL Service byte is reserved forsome unspecified “privileged” service. It is always zero.

The Routing bits indicate the type of Router and Brouter servicerequested.

Flood Routing (1,1) instructs Routers to route the packet to everyallowed medium in the network.7

Directory Routing (1,0) instructs Routers to forward the packetonto only the branches of the network in a direct path to thedestination node. Routers keep track, using address tables, of whichnetwork addresses are on which side of their two media. If thedestination address of a received packet is known to be on theother side (other branch) of the network and Directory Routing isrequested, the Router will forward the packet.

119

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

120 Chapter Six

ID Packet (0,1) and Request ID (0,0) are used for NL ID packetoperations and are explained in the ID Packet section that followslater in this Network layer discussion.

The FP and Ext bits are used for extended services requested of thedestination node and are explained in the Network layer Extended Ser-vice 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 thisbit is set, an additional Allowed Media byte follows the NL Service byte(after any Brouter address bytes) to indicate which media are allowed forpacket forwarding. This byte has a bitmapped correspondence to eachCEBus medium type. Each bit in the byte controls packet forwardingonto the medium for that bit position. A 1 bit enables forwarding; a 0 bitblocks forwarding. These bits take precedence over all other routing deci-sions. The bit positions correspond to the following media:

Figure 6.14Format of the NPDUheader. There areone to eight (ormore) possible bytesin the header. The bitfunction of each ser-vice byte is shown onthe right.

Protocol

Position Medium

20 Power Line

21 Twisted-Pair

22 Coaxial Cable

23 Fiber-Optic Cable

24 A/V Bus (medium used by AV equipment)

25 RF

26 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-orig-inating node knows what medium the receiving node is on and wants toreduce 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 isset, a 2-byte Brouter address will follow the NL Service byte (as shown inFigure 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 forwardsbetween either IR or RF and any other wired media. The NPDU Head-er Brouter address fields allow a packet to originate, for example, at anIR device, be picked up by the Brouter in the same room as the origi-nating IR device, be forwarded onto a power line to another Brouter inanother room, and retransmitted to an IR device in that room (anambitious packet).

The first Brouter address (B1) is the node address of the Brouter thatwill forward the packet onto the wired media. The second Brouteraddress (B2) is used when an IR or RF device transmits a packet thatmust be forwarded onto a wired media and then forwarded again toeither an RF or IR destination. The second Brouter address determineswhich Brouter will forward from wire back to IR or RF.

The Duplicate IR/RF Packet Problem If there is more than oneBrouter in a room where an IR device transmits a packet, all Brouterswithin the line of sight will pick up the packet and attempt to forwardit to its destination. This will result in duplicate packets arriving at thedestination node. There are two techniques available to IR or RF devicesto prevent duplicate packets. The first technique relies on knowing thenode address of one Brouter in the room where the transmitting device

121

122 Chapter Six

is being used. If the address of a Brouter able to receive the packet isknown, its address may be included in the transmitted packet in the B1address field of the NPDU Header. This will ensure that the packet isonly forwarded by one Brouter.

The second technique is used if the address is not known, andrequires that the transmitter uniquely identify each packet to the receiv-er. This is done by assigning a sequential packet number to the packet,and relying on the IR/RF duplicate packet rejection capability of thedestination nodes Network layer. The duplicate packet rejection capabilityis one part of the optional Network layer Extended Services described inthe next section. Because this service is optional, it cannot be relied onfor duplicate rejection.

In practice, there should only be one RF Brouter in a house or apart-ment because an RF Brouter should be capable of transceiving packetsto any RF device in the house. This should reduce the risk of RF dupli-cate packets. Because IR devices are line-of-sight, there needs to be atleast one RF Brouter in each room or space in which an IR device isexpected to be used. There may, however, be more than one Brouter in aroom because AV devices (TVs, VCRs, and the like) may have an IRBrouter built in. Knowing the Brouter address is an advantage.

Network Layer Extended Services

Network layer Extended Services are optional NL services requested ofthe destination node. Extended Services are only used to handle CALmessages (and APDUs) that are too large to send in one packet, and tohandle Brouter duplicate-packet rejection. The Extended Services are themost complex part of the protocol. You can skip this section if you arenot interested in segmented service or duplicate-packet rejection.

The Need for Segmented Service The total size of an NPDU is lim-ited to 32 bytes. This size limit allows products to implement small,fixed-size buffers at the Data Link layer. This size includes all the CALmessage, the APDU Header bytes, and the NPDU Header bytes. BecauseCAL messages are usually short—8 to 10 bytes—and most Applicationlayer and Network layer services require only one header byte, the 32-byte limit is usually not a problem. There are times, however, when largemessages are required. This usually occurs when a CAL message is usedto read a large data value or when a large text string needs to be sent andthe message plus header bytes exceed 32 bytes. In this case, the node has

Protocol

two choices to overcome the NPDU size limit. The application can reador send the data in smaller chunks, or the message can be segmentedusing Network layer segmented service.

Segmented service takes a large APDU and breaks it up into smallerpackets (called segments) for reassemble in the destination node’s Net-work layer. Segmented service is an optional Network layer service, and ifimplemented, comes with or without a flow control service. Flow controladds additional reliability to segmented service by allowing Network lay-ers to periodically keep track of segment transmission progress. It is typ-ically used when the APDU is large (more than 100 bytes) and requirestransmission of many segments (more than 6 to 8).

Specifying Extended Service Extended Service is indicated by set-ting the Ext bit in the NPDU Service byte. Setting the Ext bit to 1 meansthat the NPDU will contain at least two additional extended servicebytes: the Extended Service byte and one or more Packet Number bytes (seeFigure 6.15).The FP (First Packet) bit is used with the Ext bit to indicate the first seg-ment of a multisegment packet. It is set to 1 to indicate that the NPDUcontains 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 theNPDU Service byte, an Extended Service byte will follow any Brouteraddress bytes and Allowed Media byte. The format of the Extended Ser-vice byte is shown below for reference.

123

Figure 6.15Portion of NPDUheader. When extend-ed service is used (Ext 1), the ExtendedService byte, alongwith one or morePacket Number bytes,will be included in theheader.

124 Chapter Six

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

1100 Seg_service Segmented Service. This NL Service type supports seg-mented service with or without flow control.

0110 Num_Packet Numbered Packet Service. This NL Service type is usedby IR and RF devices to transmit or forward single-packet messages without including a specific addressfor the forwarding Brouter. This NPDU type permitsthe identification and rejection of duplicate packetsthat 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 positivereception of a window of packets, or a negative recep-tion (error). Used with flow control only.

1001 No_serv_support No Service Support. Used as a reply to a segmented ser-vice request from a destination that does not supportsegmented service (because it is optional).

0100 Seg_service_busy Segmented Service Busy. Used as a reply to a segmentedservice request to indicate that the destination node iseither already in the process of receiving a segmentedmessage and it cannot handle another one, or that itsmessage buffer is full. This indicates a temporary con-dition, and transmission of the segmented messagemay be attempted later.

0010 Error_msg_len Message Length Error. Used as a reply to a segmented ser-vice request to indicate that the destination node can-not process the message because its Network layer inputbuffer size (used to reassemble a segmented NPDU) can-not handle the entire message (calculated as the PacketNumber times 32).

The use of the remaining four bits in the Extended Service bytedepends on the Extended Service type selected in the first four bits. Ingeneral, their use is as follows:

M# Message Number bit. This bit is toggled with each newApplication layer APDU. The Message Number bitremains the same throughout all segments of the same

Protocol

APDU. The Message Number bit distinguishes onegroup of segments from another.

FC Flow Control bit. Indicates (if set to 1) that flow control isrequested.

Window Window Size bits (2). Used only with flow control, thesebits 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 fieldis set to 1,1 if flow control is not used.

Packet Number Bytes At least one or more Packet Number bytes fol-low the Extended Service byte. The Packet Number bytes are used toindicate 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 thenumber of segments to follow. The first segment of a message (denotedby the FP bit) has a Packet Number that is one less than the total num-ber of segments. Packet Numbers decrement with each segment. Zeroindicates the last segment. When more than 254 segments need to besent, additional length bytes are used. The initial byte is set to FFh (255)and the following byte contains the remainder segment count. As manybytes 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 wouldbe FFh, FFh, 5Ch (3 bytes). Each additional segment (599 of them) woulddecrease the segment number by one.

When Num_packet service is used by a node on IR or RF for dupli-cate packet rejection, the Packet Number contains a unique sequencenumber to enable duplicate IR or RF packets to be identified and dis-carded by the destination node. The Packet Number is a free-running 8-bit counter that starts at 255 and decrements for each new packet. If anIR/RF packet arrives that has the same sequence number from the samesource 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 caseusing segmented service without flow control. The originating nodeMTE requests transmission of a large APDU using segmented service.The NL breaks the APDU into three segments.8 This example is shown

125

8The CEBus Network layer specification does not specify how the Network layer breaksup the APDU. Each segment can contain any number of bytes less than or equal to 32, butthe 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 betweenNetwork layers of two nodes. The header shows the NL Service byte, theExtended Service byte, and the Packet Number byte used in eachNPDU transmitted.

The first NPDU shows the NL Service byte with the FP and Ext bitsset to indicate the first segment of extended service. The Extended Ser-vice byte shows that Seg_service is being used (4 most significant bitshave a value of 12), the M# happens to be 1 (for all segments in thisAPDU), and the FC bit is clear (no flow control). The Packet Numberbyte starts at 2.

The second segment has the same values except that the FP bit in theNL 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 lastsegment 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 andreceiving nodes. The contents of the NPDU header are shown for each packet sent.

Protocol

complete APDU, and when the last segment is received, it passes theAPDU to the MT Element.

Flow Control Flow control can be used with segmented services.When using flow control, the source and destination node Network lay-ers coordinate the delivery of the segments.

Flow control allows the originating node to keep track of the progressof segment transmission during segmented service by requiring the des-tination node to acknowledge reception of a “window” of transmittedsegments. The window, or segment group, can be either 2, 3, 4, or 5 seg-ments, and is determined by the value in the 2-bit Window field in theExtended Service byte. If flow control (FC) is used, the FC bit is set inthe Extended Service byte and the Window field is set to the desiredwindow size minus 2 (that is, to have a window size of 4, the Windowfield is set to 2). Errors, such as missing or out-of-sequence segments, arecorrected by having the source back up and retransmit all segmentsafter the last correctly received segment.

Upon transmission of window-size number of segments, or the lastsegment, the NL waits for a Pos_ack or Neg_ack response from the desti-nation, or a timeout condition. After window-size segments are success-fully received at the destination node (or the last segment) without error,the destination returns a Pos_ack with the Packet Number set to the lastreceived Packet Number value. The acknowledgment packet contains anull APDU (that is, an NPDU Header only).

If a missing or out-of-sequence segment is detected during reception, thereceiving node immediately transmits a Neg_ack with the Packet Numberset to the last correctly received segment number. The source node thenbegins retransmitting with the next segment after the last good one.

Flow control should only be used when transmitting to a singlenode, because transmitting to a group would cause multiple positiveand negative acknowledgments. It is not possible for a node to thenretransmit a portion of segments to one node of the group.

Flow Control Examples The second example (Figure 6.17) illustrates theuse 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 awindow size of 2. The first segment shows the same NL Service byte as thefirst example, but the Extended Service byte shows that Seg_service isrequested and the window size field is set to 0,0 indicating a window sizeof 2 (size 2 window_size). The Packet Number starts, again, at 2.

127

128 Chapter Six

After two segments are sent, the sending NL starts an acknowledg-ment Wait Timer of 10 seconds and waits for a positive acknowledgmentfrom the receiving node. When the receiving node receives the last seg-ment of a window correctly, it will immediately send a Pos_ack NPDUHeader with the Packet Number of the last correctly received segmentin the window. When the sending node receives the Pos_ack, it will con-tinue with the next window of segments. In the example shown, there is

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

Protocol

only one more segment. When the last segment is received (Packet Num-ber 0), the receiving node also returns a Pos_ack.

The third example (Figure 6.18) shows what happens when one of severalpossible errors occur in APDU transmission. The example is similar to theprevious example but the APDU is longer, requiring more segments and

129

Figure 6.18 Example of segmented service with flow control showing what happens when one ofthe 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 lostand never received by the destination node. The destination node doesreceive the third segment and immediately detects the Packet Numbererror. Because it is the last segment of the window, a Neg_ack NPDUresponse is sent to the sending node with the Packet Number of the lastcorrectly received segment prior to the detected error. The originatingnode then begins retransmission of the APDU at the segment followingthe last correctly received segment.

Similar error conditions can occur if the receiving node does notreceive the last segment of a window. In that case, its Wait Timer expiresand a Neg_ack is sent with the Packet Number of the next-to-last seg-ment. This causes the originating node to retransmit the last segmentand wait for an acknowledgment as usual.

More on IR/RF Packets and DuplicateRejection

When an IR or RF device originates a packet for transmission by a Brouterto a wired medium, the device NL can either use the node address of theintended Brouter in the NL Header, or rely on the IR/RF duplicate packetrejection 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.

Protocol

Notice that a Brouter address is still inserted even though it is notbeing used. It is set to the Brouter broadcast address (FFFFh). When areceiving Brouter forwards the packet onto a wired medium, it replacesthe FFFF with its own node address. Num_Packet Extended Service isused to indicate that the packet originated on either IR or RF and aBrouter address was not used. The Packet Number byte is set to 255. ThePacket Number decrements with each new packet sent to the same des-tination address within a 5-second window.

Duplicate packet rejection software requires, in both the transmittingand receiving side, that the NL maintain a Packet Number/sourceaddress association list for each transmitted and received packet. Oncethe first packet to that address is transmitted, a 5-second timer associatedwith the destination address is started. If the IR/RF device makes anoth-er transmission to the same destination before the timer expires, thePacket Number is decremented by one and the timer is reset to 5 sec-onds. The Packet Number continues to decrement for each new trans-mission to the same destination address until the timer expires. Afterthe timer expires, the association is discarded.

At the destination node, when an Extended Service NPDU Headerarrives with a Brouter address, the node knows the packet originated onan IR or RF media and the duplicate packet rejection algorithm is used.The received Packet Number is compared to the list of previously savedpacket numbers. If it is a new packet, a 5-second timer is started for thatsource address and the Packet Number is saved. As each new IR/RFpacket is received, the timer is restarted and the new Packet Number iscompared 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 timerallows the Packet Number list to be cleared.

IR/RF Packet Examples

The example shown in Figure 6.19 shows an RF packet being transmit-ted from a hand-held remote control device. The packet is picked up bytwo RF Brouters in the house.9 The remote control transmitted thepacket using the node address of one of the Brouters (the one withaddress 38). The NPDU Header bytes are shown in the “window” point-ing to the RF “energy.” Extended Service is not used. Instead, the B1 bit is

131

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

132 Chapter Six

set and the Brouter address is included. The packet is routed only by theintended Brouter to the power line for reception by the TV.

In the second example (Figure 6.20), the hand-held remote control trans-mits the same message but does not use the Brouter address (it is notknown). In this case, the remote control uses Extended Service for duplicate-packet rejection. Both Brouters pick up the RF packet and route the packetto PL. They substitute their own node address for the FFFF Brouter addressin the RF packet. The first packet received by the TV will set up an associa-tion table entry with the source address of the hand-held remote and PacketNumber 255. When the second packet arrives (well within the 5-secondlimit), the TV will discover that it has the same association as the first packetfrom the remote, and correctly discard the packet as a duplicate.

The third example (Figure 6.21) illustrates using two Brouters to get apacket to its destination. The RF Brouter picks up the packet from theremote. 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.

Protocol

being used for delivery, two Brouter addresses must be included in thepacket (B1 and B2 is set). The first Brouter substitutes its own address forB1 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 forreception by the TV (the destination node address). The TV knows thecomplete address return path for any reply message.

ID Packets

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

133

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

134 Chapter Six

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

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

Protocol

The ID Packet contains only a 1-byte NPDU Header. There is noAPDU in the packet. They originate and terminate in the NL. ID Pack-ets are flood routed through the network by Routers. As the ID Packetpasses through a Router, the Router updates its Directory Routing Tableentry for that particular address.

When an ID packet is transmitted by a nodes NL, the NL sets thedestination system address to the system address of the node, and thedestination node address is set to 00FF (one of the reserved groupaddresses of Routers). A typical ID packet is shown in Figure 6.22.

Data Link LayerThe Data Link layer (DLL) is responsible for reliable transmission andreception of packets over the attached medium. The Data Link layer ineach node communicates with the Data Link layer in all other nodes onthe attached medium. The Data Link layer receives requests for NPDUtransmission from the Network layer and notification of received sym-bols 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 onthe attached medium.

The individual responsibilities for message transmission and receptionare listed in Table 6.5.

The Network layer makes requests to the Data Link layer for NPDUtransmission using requested DLL services. When an NPDU is passedfrom 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

135

Figure 6.22Format of an IDpacket.

136 Chapter Six

Waits for any required acknowledgment of packet reception andperforms 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 andgroup addresses

Parses the NPDU and passes it to the Network layer if a matchoccurs

Generates and transmits an acknowledge packet if anacknowledgment packet is required

The DLL is the most time-critical protocol layer because it operates inreal time to keep up with packet reception and transmission.

DLL Structure

The CEBus EIA-600 document divides the Data Link layer into two dis-tinct sublayers: The Logical Link Control (LLC) sublayer, and the Medi-um Access Control (MAC) sublayer. The division occurred early in thedevelopment of the CEBus protocol, mainly because it is how Ethernetis designed and the Committee used Ethernet as a protocol model. AsDLL functions were refined over the years, the separation proved a bur-den and all functions migrated to the MAC sublayer. Today, the LLCserves only as a pass-through layer and is kept only as an administrativeconvenience. All of the DLL services are performed in the MAC sublayer.This is why much of the Data Link layer terminology refers to the


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

Table 6.5

Data Link layerresponsibilities.

Protocol

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

Packet Format

The first thing that the DLL does after receiving the NPDU from theNetwork layer is to build the remainder of the packet. The packet con-sists of the Preamble, Control field, Destination Address, Source Address,NPDU, and an error-detection Frame Check Sequence (FCS). The formatof the packet is shown in more detail in Figure 6.23.

The Preamble is an 8-bit random value (randomly derived for eachtransmitted packet) used for collision detection and resolution duringchannel access.

The Control field identifies the type of packet and DLL services for thepacket. The format of the Control field is shown in Figure 6.24. The fieldis divided into the following subfields:

S# The Sequence Number bit toggles between 0 and 1 for each new NPDUtransmitted. This bit is used for duplicate-packet rejection at the DataLink layer when using one of the “addressed” services (described laterin 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 capa-bility 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. Thethree priority levels determine how long a node waits to transmit apacket.

137

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

138 Chapter Six

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

The Destination (To) address and the Source (From) address follow theControl field. Both of these fields are 32 bits and consist of a 16-bitnode address and a 16-bit system address. The system address definesa specific address partition for the home to separate it from address-es used in neighboring homes. The node address is either the uniqueindividual node address of the destination node, a group address, orthe broadcast address (0000). A destination address is always required.A source address is only required if the destination node needs toreturn a reply. If a message is sent using Application layerimplicit_invoke service, and is not using a Network layer ExtendedService, and not using a Data Link addressed service, then the sourceaddress can be omitted.

The trailing Frame Check Sequence (FCS) is either an 8-bit checksum forpackets on IR, TP, or CX, or a 16-bit CRC for packets on RF or PL. For anode on IR, TP, or CX, the DLL is responsible for generating the 8-bitchecksum. 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

Figure 6.24Content of the DLLcontrol field.

Protocol

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

EOFs, EOPs, and Leading Zero Suppression

All fields of the packet, excluding the NPDU, are variable length anddelimited by the end-of-field (EOF) symbol. The packet ends in the end-of-packet (EOP) symbol following the FCS.10 The EOF symbol allows theDLL to perform leading zero suppression.

Leading zero suppression does just what it says. Each field is strippedof any leading (insignificant) zeros prior to the first 1 bit used in thefield. This accomplishes a simple data compression on the packet. Leadingzero suppression is applied to all fields except the Preamble “Packet for-mat:preamble” and the NPDU. The biggest benefit is gained in reducingthe size of the address fields. Each address field (destination and source) is32 bits, yet most system and node addresses used by devices in a typicalhome will be less than 8 or 9 bits. A high degree of compression isachieved on these fields, shortening packet transmission time. For exam-ple, assume that the destination and source address (decimal) of twonodes 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 00000000000001010000000000001101 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).

139

10For packets on RF and PL, the EOP follows the NPDU because it is generated by theDLL. 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 rein-sert the zeros because the addresses are used directly or converted to aninternal (integer) format.

Channel Access ProtocolThe DLL performs a simple—and inexpensive to implement—channelaccess protocol called CSMA/CDCR. It sounds a lot more complicatedthan it is. A node that wishes to transmit a packet waits until the chan-nel is “clear,” that is, no other packet is being transmitted. It then beginsto transmit its packet. If, during the transmission, a collision is detectedwith a packet being transmitted by another node, the node stops trans-mission and waits again for another clear period. The technique is a lit-tle more complex, but that’s the basic idea. The technique is identical tothe technique people use to access a telephone line shared by a numberof telephones (such as on a party line, or in a home with multiplephones connected to the same telephone line). When you pick up theline and hear someone talking, you hang up and try again later.

CSMA/CDCR stands for Carrier Sense Multiple Access with CollisionDetection and Collision Resolution. Carrier Sense Multiple Access sim-ply means that many nodes have access to, and are sharing, the samemedium, and sense the state of the medium (for a “carrier”) to knowwhen to gain access. Collision Detection means that each node is capableof detecting when a transmission collision occurs with another nodetransmitting at the same time. Collision Resolution means that a colli-sion 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 interfer-ing with each other. The strategy used to optimize channel access can besummarized in three methods (the telephone use analogy is given in italicsunder each one):

1. Avoid contention. If the channel is in use, wait until the channelis 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 ormore nodes attempt to transmit at the same time, all but oneshould stop transmission.

Protocol

If you and someone else pick up the phone at the same time and attempt totalk, the best strategy is for one of you to hang up and let the other personcontinue, if you both hang up, the situation will just happen again.

3. If a transmission failure occurs, allow the sending node to retrywithout relinquishing control of the channel. A node should beallowed to attempt retransmission without contention for thechannel.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 per-son to repeat what they were saying, rather than have you both hang up.

1. Avoiding ContentionThe best technique to optimize channel access is to avoid contention inthe first place. The CEBus DLL access protocol uses three methods toavoid contention.

Prioritization of channel access. Each transmitted packet can beassigned a channel access priority.

The packet priority is used by the sending node to determinehow soon it can contend for channel access after an initial 10 USTquiet period after the last packet. Packets are categorized into threepriorities: high, standard, and deferred. High-priority packets cancontend for channel access during the eleventh UST from the endof previous packet. Standard-priority packets can contend duringthe fifteenth UST. Deferred-priority packets contend during thenineteenth UST following the last packet. The three priority starttimes are illustrated in Figure 6.25. All times shown in the figureare referenced from the receiving node. This scheme insures thathigh-priority packets will only contend with other high-prioritypackets to gain channel access. Standard- and deferred-prioritypackets only gain access if there are no high-priority packets.Deferred-priority packets will only gain access if there are no high-or standard-priority packets waiting to transmit.

Priority Selection A packet channel’s access priority is determinedby the node application. The priority is selected based on the typeand use of the message. There are no fixed rules for selectingpriority, but the following guidelines should be considered.

High priority should be used for packets that involve user feedbackevents where any delay in packet delivery would cause a noticeddelay in a control function. For example, the most critical “user

141

142 Chapter Six

feedback” timing occurs when a light switch is turned on or off.The user expects the associated light to turn on or off instanta-neously. This is due to past experience with lights. If packet deliv-ery takes longer than about 0.1 seconds, the user detects an annoy-ing delay and may attempt to toggle the switch repeatedly, thinkingthe switch or light is broken or “flaky.” Similar user feedback situa-tions occur when changing channels on a TV, or turning an appli-ance on or off.

Deferred priority should be used whenever there is no rush to deliverthe information and there is no user feedback or time-criticalevents associated with the packet. Deferred priority can be used bydevices such as temperature sensors, thermostats, light-level detec-tors, or other devices that report changes that typically occur slowly.A difference of a few seconds in reporting that the outside temper-ature has changed from 78° to 79° is not time critical.

Standard priority is used for everything else. Standard priority packetsare typically used for routine message traffic that is not associatedwith user feedback but which requires delivery quicker thandeferred priority.

The packet priority is transmitted in the Priority subfield of theControl byte even though the information is primarily used bythe sending DLL to gain channel access. The priority of the packetis available at the receiving node for use by CAL or the applicationto set the priority of any reply packet returned to the message orig-

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

Protocol

inator. The reply priority is always the same as the original messagepriority.

Round-robin queuing within priority levels. A queuing algorithm isused within priority levels to prevent higher priority packets from“hogging” the medium.

Packet queuing is used to enhance the fairness of channelaccess priority. A packet waiting for transmission can be in oneof two queued priority states: queued and unqueued. When apacket is in the queued state, it can be transmitted at the earliesttime available for its priority. If the DLL gains channel accesswithout contention and transmits the packet, it then enters theunqueued state for that priority. This means that the next packetit needs to transmit at the same priority will have to wait anadditional 4 USTs prior to attempting channel access. Thequeued/unqueued intervals are shown on the packettransmission times in Figure 6.25. If, while attempting totransmit in the unqueued state, contention occurs andtransmission is stopped, the DLL reverts back to the queued statefor that priority. The next attempt to transmit the packet willsubtract 4 USTs from the access time.

This scheme allows, for example, standard-priority packets tocompete equally for channel access with high-priority packets fromnodes that have successfully transmitted high-priority packetspreviously. The same situation occurs between standard- anddeferred-priority packets. This technique prevents a node with onlyhigh-priority packets (such as a light switch) from dominatingchannel access and preventing standard-priority nodes fromtransmitting.

Randomization of start delay intervals. A random variable is also usedto lower the probability of two nodes trying to transmit at thesame time.

To increase fairness and further reduce contention, a randomnumber (from 0 to 3) is added to the earliest start UST time of thepacket. Prior to packet transmission, once the earliest start time forthe packet is determined based on priority and queued state, anadditional delay of 0 to 3 USTs is added.11 This delay is shown underthe queued/unqueued time intervals for each priority in Figure

143

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

144 Chapter Six

6.25. The added random delay reduces the possibility that two ormore nodes that are in the same priority/queuing time slot try toaccess the channel at the same time.

2. Resolving Contention in Favor of One NodeIf contention does occur, each node should attempt to resolve the con-tention in favor of one node. The technique used to resolve contentionis called SUPERIOR state deference.

SUPERIOR state deference is the primary means to avoid contentionand is the reason why all CEBus media encode packet data in a SUPERI-OR and INFERIOR state. Because the SUPERIOR state can be detectedover the INFERIOR state, a node can always detect a SUPERIOR state onits medium when it is in the INFERIOR state. If it detects a SUPERIORstate when it is transmitting an INFERIOR state, it knows that anothernode is attempting channel access at the same time. The first node todetect the contention stops transmitting its packet and waits until thepacket being transmitted is completed.

This is best illustrated by the example in Figure 6.26. Assume thatthree nodes (node A, B, and C) all attempt to transmit at exactly thesame time.12 The first thing each node transmits is the packet Pream-ble “Packet format:preamble,” a random 8-bit value. The first statetransmitted by each node is the SUPERIOR state because the idlestate of the medium is the INFERIOR state. By random chance, allthree nodes begin with a 1. At the end of the 1, they all transition tothe INFERIOR state (regardless of the next symbol). Node A’s nextsymbol is a 0 that will last 2 Unit Symbol Times; node B and C’s nextsymbol is another 1. Node B and C transition to a SUPERIOR 0 sym-bol after 1 Unit Symbol Time. Node A, still in the INFERIOR state,detects the SUPERIOR state and halts packet transmission. Node Band C continue. Node B and C then transition to the INFERIORstate. Node C’s next symbol is a 1, and node B’s a 0. The same thinghappens at node B. It detects Node C’s SUPERIOR state while still inthe INFERIOR state, and halts its packet transmission. Node C con-tinues to transmit its packet without interference. All other nodes onthe network will receive Node C’s packet successfully, including nodeA and B. The contention for the medium was resolved in favor ofonly one node (node C).

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

Protocol

3. Allow Retransmission without Relinquishing the ChannelThe third strategy is to allow the sending node to retry without relin-quishing control of the channel if a transmission failure occurs. This isimplemented in the DLL acknowledged service technique. The 10 USTchannel quiet time after each packet allows the transmitting node toregain channel access if its first attempt at delivering a packet failed. Thisservice is described in the following section.

DLL Packet Delivery ServicesThe 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 pack-et arrived successfully at its destination on the attached medium (or ata Router that will forward it to its destination on another medium).The destination node transmits a short acknowledgment packetimmediately upon successful reception of the original packet. If thepacket is not delivered, and/or the acknowledgment is not received,the sending DLL can immediately retransmit the message withoutrelinquishing access of the control channel. There are four basic varia-tions on the service that the transmitting application can choose totailor the delivery service.

Unacknowledged service

Addressed unacknowledged service

Acknowledged service

Addressed acknowledged service

145

Figure 6.26Illustration of whathappens duringSUPERIOR State defer-ence. The exampleassumes that threenodes begin transmis-sion at exactly thesame time.

146 Chapter Six

Each service is accomplished between the Data Link layer of the sourceand destination nodes. There are two service categories: unacknowledgedservice and acknowledged service. Unacknowledged service is used whenthe destination address is a group address or the broadcast address, orwhen an acknowledgment is not desired. Acknowledged service enablesthe sending node to determine the success or failure of the transmittedmessage to a single node across a single medium. Due to the way thechannel access protocol works, acknowledged service can only be usedwhen the destination address is a single-node address.

Unacknowledged Service

Unacknowledged service is the absence of an acknowledgment from thereceiving node or nodes. The DLL transmits the packet once and noacknowledgment is generated by a receiving node or nodes. This serviceis similar to the Application layer implicit_invoke service. It is usuallyused when the packet is sent to a group of nodes from which a DataLink acknowledgment is not possible. The service may be used to trans-mit to a single node, a group of nodes, or to the broadcast address (allnodes 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 Ser-vice 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 fieldmay be used if another protocol layer requires it, otherwise it is omitted.

Addressed Unacknowledged Service

Addressed unacknowledged service is similar to unacknowledged servicein that no reply is generated by the destination DLL, but it adds an addi-tional level of reliability. Addressed unacknowledged service requests thatthe DLL transmit the message multiple times to increase the probabilityof successful reception. The number of times the DLL may transmit a

Protocol

packet is governed by a number of variables kept in the DLL software.The variables determine the maximum number of retransmissions, theminimum delay between retries, and the maximum total time allowedfor retries. Basically, the DLL may transmit the packet as many times as itcan during a 750-ms maximum window (known as themax_retrans_time). The 750-ms window begins at the start of the firstsuccessful packet transmission and includes the time required for the lasttransmission. The DLL must contend for channel access on each trans-mission at the priority level of the packet. In practice, this allows thesending node to transmit the packet three or four times at most. TypicalDLL implementations usually send the packet twice because this is themaximum number of times that the longest packet can be retransmitted.

Addressed unacknowledged service is indicated by the use of theaddr_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 differentmessage sent to the same node (this is used for duplicate packet rejec-tion, explained shortly). During retransmission of a packet, theSequence Number remains the same. The Service is 0, the priority isselected by the application, and the Service is set to addr_unack_request.The Source Address must be included for duplicate-packet rejection atthe receiving node (this is why the service is called Addressed unac-knowledged service).

Addressed UnacknowledgedSequence/Address Associations

Because several duplicates of the packet are transmitted to the same des-tination address, a mechanism must be used in the DLL to rejectreceived duplicates. This is accomplished using the Sequence Numberand source address in combination at the receiving node to detect aduplicate packet. This service requires that an association be keptbetween the destination address and the Sequence Number in the send-ing node DLL, as well as between the source address and the SequenceNumber in the receiving node DLL.

147

148 Chapter Six

The association in the receiving node is used to reject all duplicatepackets that the sending node might send in the 750-ms retransmissiontime. All retransmitted packets will have the same Sequence Number (0or 1) from the same source address. The association (kept in a receivedassociation table) must be kept for 938 ms (1.25 750 ms). This time pro-vides 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 newpacket to the same node from using the same Sequence Number. Theassociation keeps the destination address with the Sequence Number(kept in a transmit association table) for 1,125 ms measured from thelast-transmitted packet to that address. This time insures that the receiv-er will always release the association first.

Addressed unacknowledged service is intended to provide higher reli-ability for messages to group addresses or the broadcast address. It shouldnot be used when an acknowledged service could be used.

Acknowledged Service

Acknowledged service requires that the destination node return anacknowledgment to the sending node if the packet arrives withouterrors (the FCS indicates no bit errors), and if the destination addressmatches the destination node or group address.

To allow nodes to send acknowledgments without having to contendfor channel access, the protocol has a 10-Unit Symbol Time acknowledg-ment window built into the channel-access protocol. This window isfree of other traffic and is used to allow a node to acknowledge recep-tion of the packet that just ended.

The acknowledgment, in the form of an Acknowledge packet, must besent by the destination node within 2 Unit Symbol Times (200 s) of theend of the received EOP symbol of the originating packet. The acknowl-edgment timing is illustrated in Figure 6.27. The originating node expectsto receive the acknowledgment within 6 Unit Symbol Times (600 s) of theend of the EOP symbol of its packet. The time difference is to allow fortiming differences in the nodes, turn around times, and propagation delayon the medium. The 200 s is referenced from the receiving node. The 600s is referenced from the sending node. Therefore, the acknowledgmentwill arrive at the sending node anytime between the third and sixth UnitSymbol Time. The acknowledgment protocol occurs prior to the earliestaccess possible by a high-priority packet queued for transmission.

Protocol

If, for some reason, the originating node does not receive the acknowl-edgment by the end of the sixth Unit Symbol Time, it will automatical-ly retransmit the message starting during the seventh Unit SymbolTime without relinquishing control of the channel. This automatic retryis part of the acknowledged service protocol. If an acknowledgment isnot returned after the retry, the DLL gives up and reports the transmis-sion 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 Serviceclass is Basic (0), the priority is set to the desired packet priority, and theService bits are set to ack_request (0 0 0). A Source address field may beused if another protocol layer requires it, but it is not necessary foracknowledged service.

Acknowledged Packet Format The destination node’s DLL returnsan Acknowledge packet if the originating packet was received correctly.This packet (Figure 6.28) has a different form than the normal messagepacket. The Acknowledge packet contains only the Preamble “Packet for-mat:preamble,” the Control field, an optional Information Field, and theFCS. This packet is generated and used exclusively by the DLL.

The Preamble “Packet format:preamble” is the same as an applicationpacket. The control field uses a service of Ack (0 0 0) as shown (Fig. 6.28).

149

Figure 6.27DLL acknowledgmentpacket transmissiontiming. A 10-UST win-dow is always avail-able after a packet istransmitted to allowthe receiving node togenerate an acknowl-edgment withoutcontention.

150 Chapter Six

The Sequence Number is not used, and the Service Class is 0. The Pri-ority 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 addi-tional DLL status information that may be used by the originating node.The possible values of the information field vary with the Service typeused. For acknowledged service, only a value of zero (meaning success) isused. Because leading zero suppression is applied to all fields except the Pre-amble “Packet format:preamble,” both the Control field and the Informa-tion field become null. The resulting Acknowledge packet is therefore just

[Preamble, EOF, EOF, FCS]

Fail Packet If the destination node receives the packet correctly, butcannot process the packet for some reason (it may be in an error condi-tion or trying to recover from an error condition), a Fail Acknowledg-ment packet is returned. This will prevent the transmitting node appli-cation from retransmitting to the same node repeatedly. The Fail packetis similar to the Acknowledge packet, but the Control and Informationfields always contain a non-null value. The Control field contains 1, 0, 0in the Service subfield. The information field contains one of the twovalues shown in the following table

Information field value Condition Cause

01 Remote Busy Packet received successfully, but receivingnode is busy and cannot process the packetnow.

80 Remote Reject Packet received successfully, but receivingnode unable to process packets.

Either returned value indicates that the destination node did notprocess the packet. The sending node must report the failure to theNetwork layer.

Figure 6.28Acknowledge packetformat.

Protocol

Addressed Acknowledged Service Addressed acknowledged servicecombines the immediate retry service of acknowledged service, with themultiple packet transmission feature of addressed unacknowledged ser-vice. Addressed acknowledged service uses the same immediate retrymechanism used by acknowledged service. The destination node musttransmit a reply. If the reply is not received within 6 Unit Symbol Times,the sending node retransmits the message starting at the seventh UnitSymbol Time. Unlike acknowledged service, if an Acknowledgmentpacket is not received after the immediate retry, the DLL can attemptanother delivery. It must, however, repeat a normal channel access cycleto retransmit (that is, it must compete with other nodes for channelaccess after the 10-unit Symbol Time channel-access quiet time).

The DLL may attempt to retransmit the packet as many times as it canduring the 750-ms max_retrans_time. The 750-ms retransmit time starts atthe beginning of the first successful packet transmission and does notexpire until the last transmission is complete. The DLL must contend forchannel access on each transmission at the priority level of the packet. Inpractice, this allows the sending node to transmit the packet three or fourtimes at most. As in addressed unacknowledged service, typical implemen-tations chose to send the packet twice because this is the maximum num-ber of times that the longest packet can be retransmitted. Addressedacknowledged service is indicated by the use of the addr_ack_request (1 01) value in the Service subfield of the Control byte shown below:

The Sequence Number (S#) toggles between 0 and 1 for each differentmessage sent to the same node for duplicate-packet rejection. Duringretransmission of the same packet, the Sequence Number remains thesame. The Service class (SC) is 0, the priority is selected by the applica-tion, and the Service is set to addr_ack_request. The source address mustbe included for duplicate-packet rejection at the receiving node.

Addressed Acknowledged Sequence/Address Associations Justlike addressed unacknowledged service, both the sending and receivingnodes must keep an address/sequence number association. Because severalduplicates of the packet may be transmitted to the same destination address(excluding the normal immediate retry), the Packet Number and sourceaddress are used by the receiving node to detect duplicate addr_ack_requestpackets. This service requires that an association be kept between the desti-

151

152 Chapter Six

nation address and the Packet Number in the sending node DLL, andbetween the source address and the Packet Number in the receiving nodeDLL. The requirements are identical to the addressed unacknowledged ser-vice; the timing requirement for the association is explained in that section.

Acknowledged Packet Format Like acknowledged service, the desti-nation node’s DLL returns an Acknowledge packet. This packet (Figure6.29) is different from the normal message packet. The Acknowledge pack-et contains only the Preamble “Packet format:preamble,” the Control field,the originating node’s source address, an optional Information Field, andthe 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 toindicate it is an acknowledgment to the addr_ack_request.

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

Information field value Condition Cause

00 Success Packet received successfully andprocessed.

01 Remote Busy Packet received successfully, but receivingnode is busy and cannot process thepacket now. Try again later.

80 Remote Reject Packet received successfully, but receivingnode unable to process packets.

100-FFFF Other Reserved for future use.

Figure 6.29Addressed Acknowl-edge packet format.

Protocol

The data in the information field can be used by the originating nodeto process a retransmission more efficiently. The Remote Reject condi-tion indicates a failure condition in the receiving node. The Remote Busycondition indicates that the packet was received successfully but that thepacket could not be processed. This is similar to a receipt_ack indicationin the Application layer. Receipt of either condition will stop the sendingnode’s DLL from retransmitting the packet.

Busy Queuing The Remote Busy indication means that the node istied up with another packet and cannot process the received node. It is an invitation to attempt retransmission after a delay. This indicationmay be returned by a node whose Network layer is busy assembling asegmented packet, or from a Router whose output buffer (to the routedmedium) is full.

When this condition is received, the sending DLL will requeue thepacket for transmission in the Busy Queue state. This state adds a delayof 12 Unit Symbol Times to the packet’s existing channel-access delay before attempting channel-access again. This added time gives thedestination node time to become unbusy and prevents unnecessarychannel traffic.

When the access delay expires the packet is retransmitted. If anotherRemote Busy condition is received, the 12-Unit Symbol Time remains ineffect for future retransmissions. If no acknowledgment is received, thedelay is set to 0 Unit Symbol Times.

DLL Service Support A node’s Data Link layer has some flexibilityin choosing which DLL service to use. In general, a node can choose touse any of the four DLL services on transmission, depending on the des-tination address type. A node must be able to support any of the fourDLL services on receive. The following guidelines should be used by theapplication when requesting a DLL service.

Unacknowledged service must be used any time that thedestination address is anything other than a single-node address(that is, a group address or the broadcast address).

Addressed unacknowledged service provides higher reliability thanunacknowledged service, but does require more channel access andgenerates more traffic.

Acknowledged service should be used anytime the destination is asingle-node address.

153

154 Chapter Six

Addressed acknowledged service provides higher reliability thanacknowledged service. It only requires more channel access if thefirst packet is lost. Because this should be a low probability,addressed acknowledged service should always be used ifimplemented.

Addressed service not only increases reliability by being capable oftransmitting a packet several times, but it can also help eliminate what iscalled 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 communicationbetween them is marginal. Node B is somewhere between A and C. Ifnodes A and C happen to transmit a packet to B simultaneously, andnode C’s packet is interfered with during transmission (an interferinglow impedance or noise source near node C appears during node C’stransmission), node B will only hear node A’s packet and generate anacknowledgment. The acknowledgment will be received by both A andC. C will assume, incorrectly, that its own packet was received and acknowledged. Addressed acknowledgment prevents this becausethe source address of the destination is returned in the acknowledg-ment. A typical DLL implementation need only implement one of theunacknowledged and one of the acknowledged services for transmission.

The Physical LayerThe 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 assembledby the DLL must be transmitted serially, one symbol at a time, on theattached medium. Arriving packets are received one symbol at a timeand passed to the DLL for reconstruction.

The Physical layer is responsible for transmission and reception ofsymbols (1, 0, EOF, EOP). It receives requests for DLPDU symbol trans-

Figure 6.30Simple example ofnear-far problem.

Protocol

mission from the Data Link layer and sends notification of receivedsymbols 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 packeton transmission and checks the CRC on reception.

It keeps the DLL informed of the current state of the medium forthe DLL’s access protocol.

The Physical layer is really two separate parts, which were formallycalled the Symbol Encoding sublayer (SES) and the Medium DependentSublayer (MDS). The Medium Dependent sublayer consists of physicalhardware that is dependent on the medium used by the node. It con-sists of whatever components or chips are necessary to electrically gen-erate the SUPERIOR and INFERIOR states on the medium. The Sym-bol Encoding sublayer may or may not be physical hardware,depending on the medium and the implementation. Implementationsof the Physical layer, including the Symbol Encoding sublayer, for PLand RF are typically all done in an IC.13 The simpler Physical layers forCX, IR, and TP typically implement the Symbol Encoding sublayer inthe same microcontroller where the DLL resides.

The individual responsibilities for the two sublayers are summarizedin Table 6.6.

155

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


Symbol Encoding Symbol encoding Symbol decodingSublayer

Symbol timing Bit-error detection

CRC generation (PL, RF) Channel state detection

CRC checking (PL,RF)

Medium Dependent SUPERIOR/INFERIOR SUPERIOR/INFERIORSublayer state generation state detection

Medium interface Medium interface

Table 6.6

Physical layerresponsibilities

156 Chapter Six

When the SES receives symbols from the DLL, it performs the symboltiming. It alternately generates SUPERIOR and INFERIOR states, andmust turn on the Physical layer for the correct amount of time to gener-ate a SUPERIOR state and an INFERIOR state. The timing of the sym-bols 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 isassumed to be a bit error.

As well as encoding and decoding symbols to and from the DLL, theSES must also inform the DLL of the state of the medium so that the DLL can implement its channel-access protocol. When the mediumenters the SUPERIOR state, the SES informs the DLL that the channel isactive (in the SUPERIOR state). When the medium enters the INFERI-OR state, the SES informs the DLL the channel is quiet (in the INFERI-OR state). The channel quiet indication is passed to the DLL each UnitSymbol Time that the channel remains in the INFERIOR state (this is sothe DLL can count channel quiet time). On media other than PL andRF, the state detection must occur within the first 25 s of the start ofthe state on the medium.

On PL and RF, because the symbols use a spread-spectrum carrier, detec-tion of a valid state can only occur after the complete arrival of the statesymbol. 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 valueto the end of the packet. All bits of the packet, excluding the Preamble“Packet format:preamble,” are used in the CRC calculation. Starting withthe first bit of the packet, the SES calculates the CRC starting with thefirst bit following the Preamble. After the DLL sends the final EOP

Protocol

symbol of the packet, the SES appends the additional 16 bits that com-prise the packet’s FCS.

At the receiving node, starting with the first bit following the pream-ble, 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 bitsas the packets FCS and compares the received value with its own com-puted CRC on the received packet. If they match, the SES informs theDLL of a successful match. The DLL then assumes that the packet iserror free. If the CRCs do not match, the SES informs the DLL of a “badpacket” and the packet is discarded by the DLL.

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

The System Address

The device system address (SA) is a 16-bit number in the range of 0 to65,536 (0 to FFFF hex). The system address is used to partition the addressspace of devices in one home from devices in another home or apart-ment residing on the same medium (such as RF or PL). The systemaddress is often called the “house code” because its primary function isto identify the house address.14 There can be more than one systemaddress in a house or apartment, although this makes device installationmore challenging.

The system address range is divided into reserved and nonreservedranges as shown in Figure 6.31. Address zero (0000) is reserved as the sys-tem broadcast address. A packet that is addressed to SA 0000 will bereceived by all nodes on the global network; that is, all nodes that canhear the packet, regardless of their current system address.

157

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

158 Chapter Six

Addresses in the ranges 0001 to 7FFF and 8001 to EFFF hex are avail-able for use as individual system addresses. Address 8000 hex is reservedfor use by any node performing address acquisition (see Chapter 7 for anexplanation). Addresses in the range F000 to FFFF are reserved for somefuture 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 aparticular system address. Each node address within a system addressmust be unique. The NA is often called the MAC address because, alongwith the system address, it is stored in the Medium Access Control sub-layer of the DLL.

The node address range is divided into reserved and nonreservedranges as shown in Figure 6.32. Node address zero (0000) is reserved as thebroadcast node address. A packet that is addressed to NA 0000 will bereceived by all nodes in the house with the same system Address ranges0001 to 00ED, 1001 to 7FFF, and 8001 to EFFF are available for individualnode addresses. Addresses 00FE and 00FF are Router broadcast addresses.These addresses are used by Routers to distribute Router configurationmessages.

Addresses 0101 to 0FFF are reserved for group addresses (allowing3,839 groups per system address). Group addresses are a special classof node addresses that can be shared by more than one node. Theyallow the formation of a logical group of devices addressable withone address. Group addresses are optional, and a device can acquire as

Figure 6.31System addressrange.

Protocol

many group addresses as it has the memory to hold. The exampleshown 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 out-side lights. This group is controlled by the light switch on the right.Every node in this group has the same group address in addition toits own unique node address (all these nodes are assumed to be inthe same system address). The other group has group address 0114hex, and consists of the outside lights that are on the front of thehouse. These lights are controlled by the light switch on the left.Three of the lights are in both groups; that is, they are outside lightsand front lights. The remaining two lights are in only one group, theoutside lights that are not on the front. The center light (NA 2005),for example, will respond to messages with a destination address of0102, 0114, or 2005. There is no priority of addresses; it will respondequally to a message from either the left or the right switch. Thelight 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 control-ling device need only store one destination address. Group addresses are apowerful tool for gaining channel efficiency and flexibility.

159

Node Broadcast Address

Figure 6.32Node address range.

160 Chapter Six

Acquiring and Keeping Addresses

A node must acquire a valid (that is, non-zero) system and node addresswhen installed in a CEBus network. A device can optionally acquire asmany group addresses as it is capable of acquiring. There are two basictechniques for acquiring the system and node address: self-acquisitionand directed acquisition. Self-acquisition means that a node acquires itsown address over the network. Directed acquisition means that anothernode on the network tells the node what address to acquire. Both tech-niques are explained in Chapter 7.

Group addresses are inherited; the “inherit” command is used to tell anode 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 toleave. This causes the node to remove or “forget” the group address.

Once addresses are acquired (node, system, group) they must be keptin nonvolatile memory. Addresses must be retained when the device isnot powered or removed from the network. A node keeps its addressesuntil given a new address, or until it is “reset” in some way that causes itto return to the factory default condition of no address.

Nodes may also need to acquire the addresses of other nodes. In theexample of the outside lights, the light switches acquired and retained

Figure 6.33An example use ofgroup addresses forlights. Each lightswitch transmits pack-ets to a differentgroup address.

Protocol

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

Implementation IssuesThe description of the protocol layers given in this chapter generally fol-lows the description given in the EIA-600 document. As mentioned atthe beginning of the chapter, the description of the protocol is intendedto represent a model in which each layer operates independently fromother layers, and communication between layers is by a set of “serviceprimitive” calls with arguments. Timing of events within each layer isalso treated independently. In practice, the functions of each layer areclosely interrelated, and an actual software implementation can combinetimers, buffers, and overlapping error conditions.

The EIA-600 protocol parts describe a protocol behavior. They are notintended to describe an implementation. A CEBus-compliant node,when tested for proper operation, must exhibit the specified protocolbehavior in terms of packet construction, correct use of packet fields,and correct transmission and reception timing. How the behavior isactually achieved is up to the product developer.

The following implementation guidelines may be helpful.

Each protocol layer maintains several event timers. These timersshould be closely coordinated. For example, the explicit_invoke WaitTimer in the Application layer MTE should take into account theservices used at lower layers (Network, and Data Link). If segmentedservice is used, the transmission time of a packet will bemultiplied 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.

161

162 Chapter Six

Message-association tables used in each layer can generally beallocated from one association table “pool.”

If large messages are supported in the node (where segmentedservice is used), only one message buffer is needed (for eachdirection), 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 applicationor upon reception by the Data Link layer. The packet fields definethe services required by each layer.

Layer System Management

The EIA-600 protocol layer description relies on an element called layer sys-tem management that coordinates the global operation of the protocol soft-ware layers, and handles conditions such as startup and reset conditions,errors, and other management tasks. In practice, layer system managementsoftware is the node appellation software—that part of the applicationsoftware that interfaces to the protocol code to manage its operation.

Some of the required tasks of layer system management are given inthe following list.

Setting the protocol software to a known state upon powerup orreset. This includes clearing and setting buffers, timers, tables, andthe like.

Resetting the protocol software to a known state if anonrecoverable error condition occurs in the protocol.

Causing the Network layer to generate an ID packet on powerup orreset.

Transferring any new system, node, or group address from the CALContext data structure to fields in the Data Link layer (for use bythe DLL for address comparison).

Setting temporary system and node addresses in the Data Linklayer during address acquisition.

It is also responsible for any housekeeping task that is not isolated to asingle protocol layer.

CAL7CHAPTER 7


164 Chapter Seven

The message portion of the packet (the message portion of the APDU)contains the CAL commands. The CEBus Common Application Lan-guage (CAL) provides a comprehensive command syntax for residentialproduct control. CAL defines what products say to each other. By estab-lishing a common product model and common set of commands, resi-dential products are able to communicate with other products withoutknowing 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 pro-gramming language like C or Pascal.1 CAL consists of two major parts:the definition of a data structure that models product operation, and acommand syntax that defines the operation of a set of methods on thedata structure. Although CAL adheres to many object-oriented princi-ples typically found in languages such as C, it is not an object-orient-ed language.

CAL messages originate from, and are received and parsed by, the CALinterpreter. The CAL interpreter is an element within the Applicationlayer. It provides services to the application, including resource allocationand control functions. CAL, in turn, uses the services provided by theMessage Transfer Element (MT Element) of the Application layer to com-municate with other nodes.

CAL GoalsCAL’s design requirements were determined early in its development bythe CEBus Language Working Group:

It must be common among all residential devices. CAL’s strength is itscapability to model and control any consumer device found in thehome through a common set of data structures. These predefineddata structures ensure application-level interoperability.

It must allow both control and data acquisition functions. Devices must becapable of performing control functions, and to acquire data fromother devices, either actively by asking for the data, or passively byproviding a destination for data broadcast on the network.

It must allow network management administration and managementfunctions. All of the “housekeeping” functions required by a node

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

CAL

must be performed by the language. Tasks such as acquiring anaddress, allocating resources, finding out what devices are on thenetwork, configuring other nodes, and the like, can be performedby any node using CAL.

It must be reusable and extensible. The independence of Contextoperation allows CAL to adapt easily to future products in thehome without having to foresee every conceivable new product. Ifnew products require some new Context (a toastwasher, forinstance), then a new Context can be created.

It must be customizable. A manufacturer must be capable ofhandling unique product functions not provided in the publishedCAL specifications. The syntax must allow the use ofmanufacturer-developed Context and object data structures, as wellas custom commands, while still being assured that they will notinterfere with or be interfered with by other nodes on thenetwork.

It must be easy to implement in common microcontrollers. A CALinterpreter and data structure must be capable of being coded andmust run efficiently in 8-bit microcontrollers with memory spaceavailable for the protocol and application code. It should be possibleto add necessary CEBus software to existing microcontrollers inexisting applications without the need to add additional processors.Manufacturers must be free to trade-off complexity for speed andavailable memory resources depending on the application.

All of these requirements have been met. CAL, and all other CEBus-required components, have been implemented successfully in devices assimple as a light switch and as complex as wide screen TVs.2 CAL can beimplemented at a reasonable cost in any consumer product.

How CAL Models the ConsumerProduct WorldIt is not possible to know how to operate all consumer products in thehome over a network. There are just too many different kinds of products.

165

2A light switch is considered to be a “lowest form of life” product. It is used as a bench-mark 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 consumerproducts perform and try to find a commonality, by product category,among those.

CAL’s design is based on the assumption that all electrical appli-ances and products in the home have a hierarchical structure ofcommon parts or functions, and that the basic operation of thecommon functions is the same from product to product. CAL treatseach product as a collection of one or more of these common partscalled Contexts. Contexts are designed to allow access to productfunctions in a uniform way. They are designed to work together overthe CEBus network to implement Application layer interoperabilitybetween products.

The Context Data StructureThe CAL Context data structure is a software model in each CEBus-com-pliant product that models the operation of all the functions available inthe product. The data structure is defined by the Context definitions inEIA-600 and the Context documents published by the CEBus IndustryCouncil.

Contexts

A Context defines a functional “subunit” of a product whose opera-tion can be defined and remains the same regardless of where it’sused. A typical example of the Context model can be found in aCEBus-compliant TV. A television is too general a product category tobe modeled directly because TV is not specific enough. Some TVshave a clock, some have an audio amplifier, some a tuner, and somehave built-in surround sound. TVs, however, are made up of one ormore audio/video functions such as tuning, video display, audioamplification, and so on. Each individual function can be welldefined. Any CEBus-compliant TV, therefore, can be modeled as a col-lection of Contexts at a network node address (see Figure 7.1).

Depending on the features of the model, a CEBus-compliant TVmight contain a video display Context, an audio amplifier Context, atuner Context, a clock Context, a user interface Context, and so on.

CAL

CAL defines over 60 different contexts for everything from lighting,security, and heating/air conditioning to washing and drying. Each Con-text, regardless of what product it’s in, operates the same way. The audioamplifier in the TV, stereo receiver, the speakerphone, and the intercom allwork alike. If a CEBus product knows how to set the volume in the audioContext in one product, it knows how to set the volume in all CEBus-compliant products.

The current list of CEBus Contexts is given in Table 7.1. The list isorganized by Context class number and by industry group. BecauseContext development is a continuing activity, the list is changing andgrowing. For the most current list, contact the CIC. The section“Where Do Contexts Come From,” later in this chapter, discusses thedevelopment of Contexts.

Two other Context industry groups exist for future context develop-ment: Communications and Computers.

Objects

As shown in Figure 7.2, each Context consists of one or more objects. Anobject represents a software model of a control function of a Context. Inthe figure, only 4 of the 20 objects used in the actual CEBus Audio Con-text are shown. The volume, bass, and treble analog control objects, andthe mute binary switch object represent control functions typicallyfound in audio amplifiers.

Objects model tasks performed by users to control a product. To turna 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

167

Figure 7.1CEBus nodes consistof one or more Con-texts. Each Contextdefines a genericproduct function.

168 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

Table 7.1

Existing CEBusContexts

CAL

stereo receiver, or to raise or lower the temperature on the thermostat,you use a control (knob), defined in CEBus as an Analog ControlObject. All analog controls are similar; they have minimum and maxi-mum values, and can be set to any value between. Other controls foundon consumer products include multiposition switches (such as theswitch that selects the audio source on the stereo receiver) and keypads.In addition to control objects, sensor objects provide information abouta product function such as temperature, position, level, or time. Analogsensors, such as temperature sensors or light-level sensors, are the sensingequivalent of an analog control—they have minimum and maximumvalues, and can assume any value between.

The definition of an object is generic, modeling a general class ofcontrol or sensing tasks. However, when an object is used in a specificcontext, it assumes a specific instantiation of a function of the Context,such as volume or temperature control. In the previous example of theTV, the audio amplifier Context shows a binary switch object for mut-

169

Class Context Name Class Context Name

Environmental Control Convenience

43 Environmental Zone 83 Door/Gate ControlControl

44 Environmental Zone Equip. 84 Pool/Spa

45 Environmental System 85 Pool/Spa Control

46 Damper Control 86 Bath

87 Fountain

Figure 7.2Each Context consistsof a set of objects.Objects model thecontrol functions ofthe Context.

Table 7.1

Existing CEBusContexts(Continued)

170 Chapter Seven

ing, and three analog control objects for volume, bass, and treble. Theserepresent instantiated uses of the Binary Switch object, and the AnalogControl object for this application.

CAL has 23 predefined object models available for use in making Con-texts. 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 itsclass number, and an icon for easy identification in Context diagrams.The purpose of the arrowlike shape of each object is explained later inthis chapter and in the section on object binding.

Certain objects handle functions unique to CEBus-compliant prod-ucts such as the Data Channel Receiver and Transmitter, and NodeControl and Context Control objects. The Node Control and ContextControl objects provide storage locations for information about theproduct and implemented Contexts.

Figure 7.3Icon representationof the objects used tomodel the variouscontrol and sensefunctions of a con-text. The diagram ofeach object containsits class number andname. When used inContext diagrams,the object name isreplaced with thename of the objectfunction.

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

CAL

Object Definitions

Objects are defined by a set of instance variables (IVs), as illustrated inFigure 7.4, that specify the operation of the control or sensing functionof the object. The Binary Switch object shown in the figure contains avariable (current_position) that indicates whether the switch is on or off,the default position (default_position) of the switch, and several otheroptional IVs. IVs are just like variables in any software program, having alength or size and a data type. All network operations on Contexts areperformed by reading or writing to object IVs.

The IVs that define an object are listed in the object tables in theCAL specification. There is a table for each of the 23 objects. Appendix Acontains a version of the CAL object tables.

Figure 7.5 is a copy of the Analog Control object table. The objectclass and name are given on the top line. The description section givesthe general intended use of the object including any restrictions, specialuse information, or recommendations. The description is followed by alisting of all IVs defined for the object class. The IV list contains thelabel, storage class, data type, name, and description. Any IV label andname in bold type (such as the current_value in the table) represents arequired IV in the object. If the object is used, the required IVs must besupported per the requirements of EIA-600 for the data type.

IV Categories The IVs in an object can be categorized into three gen-eral groups: support IVs, reporting IVs, and active IVs.

Support IVs are usually read-only variables that define the installationuse of the object and operation of the active IV. These values usuallydefine the units of measure, minimum and maximum values, or otherattributes of the active IV. Their use is almost always optional, and theyprovide other nodes on the network more detailed information about aproduct’s operation. In the analog control object in Figure 7.5, the first

171

Figure 7.4An object consists ofa group of instancevariables that definethe operation of theobject.

172 Chapter Seven

group of IVs fall into this category. They are optional, read-only IVsused to define the behavior of the active IV.

The active IV (or IVs) of an object is the variable that is primarily setor read to operate the object. This variable is usually called the cur-rent_value, current_position, or current-something. It is always requiredand contains the state or value of the object. It may be read-only orread/write.

The reporting IVs are always present if an object is capable of generat-ing a message via the CAL Interpreter using object reporting. TheseIVs contain the reporting address, condition, and message fragment(header) information necessary for the CAL interpreter to know whenand where to send the message. Reporting IVs may be read-only orread/write depending on how the IVs are to be configured (at the fac-tory or in the field).

IV Labels In each object table, IVs are identified by an ASCII label inthe 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-

Figure 7.5Analog Controlobject table as givenin the EIA-600 docu-ment. The table con-tains an entry foreach IV showing theIV label, access, datatype, name, and adescription of the useof the IV. This figureillustrates the generalcategories of IVs inthe object: support,active, and reporting.

CAL

ed by uppercase, for IVs that commonly occur in most objects. Theremaining IVs in each object, unique to the object, are labeled usinglowercase letters. There are only a few, seldom used, IVs that requiremore 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 prod-uct application software. In Figure 7.5, the second column indicateswhich IVs are read-only (R), or read/write (R/W). For example, theunits_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 inthe standard, it must be implemented as read/writable, but if an IV isgiven as R, it can be implemented as read-only or read/write at the dis-cretion of the manufacturer. Write-only IVs are allowed but, as of thewriting of this book, none have been defined.

IV Data Types IVs have a data type just as do variables in a program-ming 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, indi-cates the data type of the IV. For example, the units_of_measure IV isnumeric. The following paragraphs define the data types and indicatehow the data is represented in IVs and in a CAL message.

Boolean A boolean variable can hold one of two values: 0 or 1 hex,corresponding to False and True respectively. Boolean values are trans-mitted in a message as a 0 or 1 hex byte.

Numeric A numeric variable may contain any numeric value; integer orreal. Numeric values are always transmitted in a message as an ASCIIstring 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 transmittedas ASCII characters , 3, 5, ., 8. The standard recommends that numbersthat can be represented by four or fewer digits be transmitted in theform ±n.n. Numbers longer than four digits may be exchanged using sci-entific notation. For example, 1788 and 89.55 are transmitted as shown,while the number 0.00008 may be transmitted as 8.0E-5.4

173

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

174 Chapter Seven

How numbers are represented in a product is not specified. Numbersmay be stored as integer or real values at whatever precision is sufficientfor the application. For example, if an IV value is stored internally using8 bits, and the number 24.39 is received, only 24 (the integer portion) isused and retained. The range of values a particular numeric IV canassume is usually defined in the Context definition containing theobject. It is the responsibility of the manufacturer to hold the specifiedrange of numbers given in the Context definition.

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

<LITERAL><character string bytes>

The LITERAL token (EC hex) is needed to parse the bytes as a characterstring where it might be confused as an IV label.

Note: In the syntax examples used in this book, anything enclosed inthe “< >” characters is an element identifier and may be made up of oneor more simpler elements. Anything enclosed in bracket characters “[ ]” isoptional.

Tokens are a set of reserved bytes in the E0 to FE range that are used inthe message syntax to represent predefined operations or to simplifymessage parsing.

Data A data variable is defined as a fixed length block of memory. Adata IV can hold any number of bytes (up to its length) of any binaryvalue 00…FF hex. The application and/or CAL Interpreter must keep trackof the length of the last data written and the total length of the IV. Datavalues are transmitted in a message with a data identifier header indicat-ing the size of the data. The format is:

<DATA><ASCII length string><ESCAPE><data bytes>

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

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

CAL

<DATA> 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 whichIVs are required in the object when implemented in a context. OtherIVs listed in the object are optional. All required and optional IVs usedin an object must conform to the object specification. The required IVsprovide operational information necessary to use the object. The cur-rent_value exists in most objects and contains the primary modelingparameter of the object. In Figure 7.5, only the current_value IV isrequired 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 innonvolatile memory and must be retained during a power outage. Read-only IVs, when used, are normally kept in ROM. Read/write IVs are nor-mally kept in volatile memory (RAM). The type of memory useddepends on the application and whether the last value in an IV needs tobe retained during power loss. For example, the current channel num-ber of the Tuner object is a read/write IV, but it may be necessary toretain the last value of the IV when the TV containing the IV is turnedon. The manufacturer should always consider the consequences of los-ing the value of an IV or resetting the IV to a default value due to apowerout or power-up condition.

Using Support and Reporting IVs Generally, read-only IVs are notused directly by the product; they are provided so that other nodes—that care to read them—can determine the specific application of theobject. For example, in the Analog Control object in Figure 7.5, the units_of_measure, step_size, step_rate, min_value, max_value, anddefault_value IVs are used to define the characteristics of a particular useof the object. None of these IVs are required, but they may benefitother nodes for two reasons:

The IVs may hold values that differ from the default orrecommended values given in the Context specifications where theobject is used

175

176 Chapter Seven

The manufacturer provided the values to aid in using the objectwhere 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 agroup to determine the conditions that cause an object to send a mes-sage to another node. Their use is described in more detail later in thischapter.

Manufacturer-Defined IVs The IVs listed in the object tables arethe minimum needed to define the operation of the object. However,when an object is instantiated in a Context, additional IVs may beadded for a unique function required by the object in a specific Con-text. These IVs are defined when the Context is created by the workinggroup that developed the Context, and become a permanent part of theobject only in that particular Context.

Manufacturers may also add additional IVs to an object if their par-ticular product requires them. Additional IVs must behave according tothe rules for the IV data type, and not interfere with the function ofpredefined IVs. IV labels starting with the letters I, J, K, L, W, X, Y, and Zare reserved for manufacturer use only. IVs added by manufacturersexist only in that manufacturer’s product, and are not recognized aspart of the CAL specification.

Object Instantiation Contexts, like objects, are defined by a set oftables that give the definition of the Context, the Context class, and a listof the objects used in the Context. Contexts contain no data or informa-tion other than the objects that comprise the Context.

When a Context class is created, object classes are instantiated in theContext. Instantiation occurs when an instance of an object class is givena specific function in a Context, and the IVs take on specific valuesapplicable to the Context. Figure 7.6 shows how the Analog Controlobject (class 07) is used in the Audio Amplifier Context (class 10). This fig-ure shows the Context table entry for the Volume Control—an instantia-tion of the Analog Control object. Here the object is given a particularfunction, that of controlling the volume level of the amplifier. The tableentry shows the name of the object (Volume Control), its object class(Analog Control), the function of the object, and the standard list of IVsused in the object. The list includes the IV Context function that givesany specific values or use of the IV in the Context.

In this example, the first seven IVs are assigned a specific value orrange of values for the volume function. When this object is used in a

CAL

product with an audio amplifier function, using the Audio AmplifierContext, each IV (if implemented) must use the values shown in theContext table. The current_value IV is the only IV required, and assumesthe values 0 to 100 (because the units_of_measure is a percentage of fullscale). The current_value range corresponds to the minimum and maxi-mum volume range.

Figure 7.7 shows an example of the same Analog Control objectwhen used in a different Context. This example shows the HeatingSetting object in the Environmental Zone Context (40). Here, the sameobject is instantiated for a different function. The same IVs are used,but they assume a different meaning. The current_value IV assumesthe function of the current heating setting. When implemented, thisIV can only assume values between the min_value and max_value IVvalues. 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. Errormessage details are given in the Message Responses section in thischapter.

Objects are reusable both within the same Context and across Con-texts. By using the same model for different instances of objects, theoperation of each object is the same regardless of where it is used. Thisassures the operation of CAL commands on the same object class in dif-ferent products will produce the same result.

Contexts are also reusable within the same product and across prod-ucts. If a product knows how to operate an Audio Amplifier functionin a TV, it can operate an Audio Amplifier in the intercom, speakerphone, or stereo receiver.

177

Figure 7.6Analog Controlobject instantiated inAudio Context as avolume controlobject.

178 Chapter Seven

Context Data Structure

The Context and object data structure in a product is designed as a treestructure (see Figure 7.8). The message portion of received packets isdirected toward a particular object in a particular Context. Each Contextis referenced by its class number, while the objects in each Context arereferenced by the order in which they are listed in the Context defini-tion, starting at 01. Objects are referenced, within the Context, by theirnumber rather than their class because there are typically many copiesof the same class within each Context.

Every CEBus product contains the Universal Context (00). The Univer-sal Context contains the general product data, address, and other pro-ductwide information. All other Contexts are optional and depend onthe functions that the product supports.

Object Implementation Objects are coded as a set of IV data vari-ables, and application software associated with the variables. Figure 7.9illustrates the interface between the object IVs, the application code, andthe CAL Interpreter. Unlike objects in C, or other object-orientedlanguages, CAL object variables are “exposed” to the network throughthe CAL Interpreter. The application code that implements the functionof the object is hidden. IVs may be thought of as the interface betweenthe product application and the “outside world” of the network. Unlessprotected, IVs can be read or written by any node on the network.Incoming messages either read the values of the variables or write newvalues. The application code does the same; it checks for changed valuesand acts accordingly, or updates the values. The CAL interpreter can be

Figure 7.7This is the same Ana-log Control objectshown in Figure 7.6except that here it isinstantiated as theHeating Settingobject in the Environ-mental Zone Context.

CAL

programmed to send any new IV value—changed by the applicationsoftware or by an incoming message—to any other object on the net-work, 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

179

Figure 7.8Representation of theContext/object datastructure. A devicemay contain anynumber of Contexts,depending on thefunctions that theproduct supports orinteroperates with onthe network.

Figure 7.9Representation ofobject implementa-tion. The object datastructure (IVs) is acces-sible by the CAL Inter-preter and the objectapplication code.

180 Chapter Seven

whether the object is primarily a sender of messages, a receiver of mes-sages, or both. Objects are represented by one of three symbols corre-sponding to the network type.

Network output objects generate messages. The current_value IV isread-only and the object is used to originate report messages. Typicalnetwork output objects include the binary sensor, analog sensor, andmultiposition sensor. Messages are generated when the objectcurrent_value changes by some amount.

Network input objects receive messages. The object’s current_value IVcan be set from an incoming message, but it does not generate a mes-sage. Typical network input objects include the Meter, Display, and Syn-thesizer/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 sentbased on local current_value changes. The change may be the result of anincoming message, or a local application change. Typical network I/Oobjects are the Analog Control, Binary Switch, and Multiposition Switch.

All of the objects (except the Node Control and Context Controlobjects) fall into one of the three network type categories, as shown inFigure 7.10. The object type symbols are used to develop Context inter-connect diagrams that show the interconnectivity or binding from anobject in one Context, to an object in another Context.

Object Binding: How Contexts Work Together

Object binding establishes an address correspondence (stored in theobject reporting IVs) between a network output object and one or morenetwork input objects. Network output objects always send their output

CAL

to network input objects. For example, in Figure 7.11, the Binary Sensorobject 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 Switchobject. There is no other object that can receive the binary value outputof a Binary Sensor object. The only information required for bindingby the Binary Sensor object is the system/node address and Context ofthe destination node. The destination object (Binary Switch) is implied.

This relationship between specific object classes is intentional. Mostnetwork output objects bind to specific network input (or input/output)objects of the same data type (that is, the data type of the reported IVand receiving IV are the same).

Binding also extends to Contexts. Most of the objects in each CALContext are intended to work (or bind) directly with specific objects inother Contexts. Context binding implies a predefined interoperabilitybetween Context classes.

A Context interconnect diagram defines Context binding and illus-trates how two or more Contexts work together. Figure 7.12 shows a

181

Network Output

Network Input

Network Input/Output

Binary Sensor Binary Switch

Analog Sensor Analog Control

Medium Transport

Matrix Switch

Clock

Dialer

Counter/Timer

Keypad

Multiposition Sensor Multiposition Switch

Data Channel Trans

Data Channel Rcvr

Meter

Motor

Display

Synth./Tuner

Tone Generator

List Memory

Data Memory

Figure 7.10Classification of eachobject as NetworkOutput, NetworkInput/Output, or Net-work Input.

182 Chapter Seven

simple example of a Context interconnect diagram for two of theHVAC Contexts. The Environmental Sensor (41) Context is intended toreside in any device that measures temperature and/or humidity. Theobjects in this Context bind to a set of corresponding network inputobjects in the Environmental Status Context (42), which is intended tobe used in any product that needs or wants to know the inside oroutside temperature or humidity. This might be a thermostat, a TV, ora PC. The objects in the Environmental Sensor Context send messagesreporting a change in temperature or humidity to the EnvironmentalStatus Context—there is no other Context/object for the output mes-sage to go. This design makes interconnecting or binding products inthe field easy because only the system and node address of the devicecontaining the Environmental Status Context needs to be known. Aproduct designer knows where network output object messages willbe sent.

The diagram also indicates another important attribute. The diagramremoves any ambiguity about which Context supplies information andwhich Context receives information. A product designer that incorpo-rates the Environmental Sensor Context knows that the product willsend new temperature and/or humidity values, rather than wait foranother product to read the values. A product designer that uses theEnvironmental Status Context knows that if temperature and/or humid-ity is available (another product is measuring it), it will be written to the

Figure 7.12Context interconnectdiagram for two ofthe HVAC Contexts.

Figure 7.11Example of objectbinding. Outputobjects always sendmessages to networkinput (or input/out-put) objects.

CAL

corresponding objects. The product does not have to read it. This pre-vents a situation where one manufacturer assumes the information inhis product will be read, and another manufacturer assumes the infor-mation will be written, and neither product communicates correctly.

Figure 7.13 is a portion of another HVAC Context interconnect dia-gram. This shows the Environmental Zone Control Context (43) andthe Environmental Zone Context (40). The Environmental Zone Con-trol Context is intended to be used in products that need to controlheating/air-conditioning equipment. This Context might be in a tele-vision, a PC, or a home automation system. The Environmental ZoneContext is intended to be used in heating/air-conditioning equip-ment, in particular, a thermostat or equivalent product. Note that theEnvironmental Zone Context is bound to another Context not shown(the Environmental Equipment Context (44)). Context 43 is typical ofmany Contexts intended to be used in control products (that is, prod-ucts that contain a user interface, or control algorithms, and that allowthem to directly control other classes of products). An example is atelevision or PC with an onscreen menu that allows the user to selectthe heating and cooling setting for the house. User selections changethe values in the Zone Control Context. This causes messages to besent to the Environmental Zone Context in the thermostat to changeits settings.

Contexts do not have to bind to or be bound by other Contexts, butContexts do provide a convenient control model. Many Contexts (the

183

Figure 7.13Context interconnectdiagram for twoHVAC Contexts. Con-text 43 is intended tobe used in non-HVACproducts that need tocontrol or monitorHVAC zones. Context40 is intended to per-form the functionsnormally associatedwith a thermostat.

184 Chapter Seven

Audio Amplifier (10), Time (04), Camera (16), and so on) do not have apublished predefined binding with other contexts. They are used “as is,”and any binding must be developed during installation or provided bythe manufacturer.6 The Context Development Committee of the CIC isconstantly working to develop interoperable relationships between mostof 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 lightnode in which the light switch controls the light. The Light Level Set-ting object in the Lighting Context (found in the light switch) isdesigned 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 LightLevel Setting usually binds to the Light Level Control Object in a spe-cific light node or groups of light nodes. This is because light switchesusually control a specific light, selected when they are installed. All thatis required is the system/node address of the light. The Light Level Set-ting Object always sends its messages to the Light Level Control objectin the Lighting Context.

A more general (and desirable) binding exists for many types of con-sumer products that do not require the destination node address. Figure

Figure 7.14An example of objectbinding to all of aparticularContext/object in thesystem address. Allnodes that containContext 42, object 3(outside temperature)will process thebroadcast message.

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

CAL

7.14 illustrates an outside temperature sensor device. The temperature sen-sor device contains the Environmental Sensor Context (41), and uses theOutside Temperature object (03). This product is intended to bind to ALLEnvironmental Status Contexts (42) and Outside Temperature objects (03)in the home, reporting outside temperature to any product that needs orwants the information. When the Outside Temperature object in Context41 sends a message reporting an outside temperature, it uses the house sys-tem address, Broadcast node address (0000), so that it will be received by allnodes in the house.

The message containing the outside temperature is picked up by anynode in the house containing the Environmental Status Context/Out-side Temperature object, such as the living room television and the heatpump thermostat. Binding via the broadcast node address makes fieldinstallation of products an easy task.

Context ExamplesAppendix B contains two sample Context tables (Audio and Lighting).Each of the Context descriptions starts with a header that defines thename of the Context, and the Context class number (in hex), followedby a brief description of the general use of the Context (Figure 7.15).

The Audio Context contains necessary objects for the majority ofaudio amplifier functions. The basic Context usage assumes one ortwo channels, but additional objects are provided for four-channeland surround sound applications. The Audio Context is intended foruse in A/V as well as non-A/V use (such as in intercoms and speaker-phones).

185

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 non-A/V use (such as in intercoms, speakerphones, etc.).

Figure 7.15Typical Context head-er information. This isthe header and firstobject of the AudioContext (10).

186 Chapter Seven

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

The Universal Context

Every CEBus node must contain the Universal Context (00). The UniversalContext does not model any functional system of a product. Rather, itstores the global CEBus housekeeping information about the node in theNode Control object. The Universal Context may optionally contain aspecial function Data Memory object called an Event Manager. The EventManager object can be used to download program code, CAL com-mands, or other data to the node over the network.7 The information inthe Event Manager object is assumed to be manufacturer specific.

Node Control Object The Node Control object (01) is the storagelocation for global device information such as the system and nodeaddress, the product serial number, and other information that applies tothe entire product. IVs in the Node Control object are provided to facili-tate product identification on the network, aid address configuration,and determine product capability. Figure 7.16 shows the contents of thenode control object.

Only the IVs in bold type are required. However, many of the IVs aredesigned to enhance interoperability and should be used if possible. Abrief discussion of some of the key IVs follows.

The optional power IV (w) is intended to control the “global” power toa device and is applicable only to products whose on/off function is notincluded as part of other contexts in the device. Typical products thatmight use the power IV are TVs, VCRs, and computers.

The on_offline IV (l) can be implemented to allow a device to go off-line for service or manual control. When on_offline (l 0), a node willonly 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 num-ber. It should be 18 characters or less and contain any combination ofASCII characters. Knowing the serial number of a product allows uniqueidentification of the node and is useful for device address configuration.

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

CAL

The CIC can assign a manufacturer a unique first five-charactercode to be used as the first five characters of a manufacturer-suppliedserial number for all products built by that manufacturer. This insuresthat no two CEBus-compliant products will inadvertently have thesame serial number.

The product_class IV (c) is used for product-type identification. TheIV contains a number indicating that the product belongs to a specificproduct category. The list of numbers is given as an appendix to theCAL specification. A portion of the list is provided below (numbersare decimal).

1 TV 50 Microwave

2 Video Monitor 51 Stovetop

3 VCR 52 Oven

4 Audio Recorder 53 Refrigerator

5 Amplifier 54 Freezer

187

Figure 7.16Node Control objectused only in the Uni-versal Context.

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. Forexample, to locate all the VCRs in the house, a message is sent to thebroadcast node address to retrieve the specific node address of deviceswith product_class of 3:

[00,01] if (‘c’ EQ 33h) getArray ‘a’(getArray is a “method” [describing the action to be performed] toreturn an array of data from the IV)

Manufacturers are encouraged to implement product class IV because itis very useful for network configuration.

The system_address (h) and unit_address (a) each hold a 16-bit binary addressforming a 32-bit network address for the product. Prior to being installed, aproduct’s system and node address are unknown (usually set to zero). Wheninstalled, these addresses must be acquired. The group_address (g) optionallyholds one or more 16-bit group addresses. The number of group addressesthat a product can hold is up to the manufacturer, but a minimum of oneis recommended. The storage allocation for the IV must be adequate to

CAL

hold the desired number of group addresses. The inherit and disinheritmethods are used to add and remove group addresses from the IV.

The capability_class IV (b) is a rough indicator of the CAL capability ofthe node. Currently, the IV is a number from 0 to 3 defining four classes.The number defines the minimum guaranteed capability, but the productmay always do more.

Class 0 devices support only the minimum object/IV/methodrequirements.

Class 1 devices support all objects/methods/IVs that are explicitlyidentified in the Context specifications used.

Class 2 devices support class 1 devices plus a minimum of twogroup 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 con-texts used in the node. The context list uses the context ID syntax:context number followed by the context class (two bytes) for each con-text used. This IV can be read by the getArray method to determinewhat contexts are in the node.

The configured, setup, user_feedback, and config_master IVs are used foraddress configuration; to allow the node to acquire a system and nodeaddress and, if implemented, allow address propagation to other nodes.The recommended procedure to acquire a system and node address andto propagate a system address to other nodes in the same house, isdescribed in the section on address configuration in this chapter.

The configured IV (f) indicates whether the device has acquired a validsystem and node address. Prior to installation and configuration, the IVis 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 setto 1 during installation and is incremented to ensure only one device istrying to configure the node.

The user_feedback IV (u) is intended to provide, through an applicationinterface, an indication to the user. The indication is primarily intendedto assist in address configuration, but it can be used for other functionsas well. Some user_feedback values have been preassigned to assist addressconfiguration.

0 Off, no feedback.

1 Initiate an external indication for a specific length of time, such asblinking an LED for 30 seconds, so that the user can locate the

189

190 Chapter Seven

device being configured. The IV value returns to zero followingthe indication.

2 Provide feedback that the configuration process completed success-fully.

3 Provide feedback that the configuration process did not completesuccessfully.

The config_master (t) is a boolean IV implemented only in devices thatcan acquire and propagate their system address. The IV is always FALSEunless the node has acquired the config_master resource.

The source_unit_addr (d) and source_system_addr (e) hold the source nodeand system address of the last received message.

The conformance_level (v) is a character string that indicates a version ofCAL that the product is using. The present level of the released standardis 1.0. This value will only change if a significant change is made to thelanguage to add additional capability.

The authentication_keys (k) are used in the message authentication algo-rithm. They are only implemented if message authentication is requiredin the node.

Finally, the reporting IVs can be used to report a change of conditionsuch as power changing from on or off.

Context Control Object

The Context Control object is found in every context. It contains onlyone read-only IV, the object_list (o). The IV is read with the getArraymethod to obtain a list of all the objects implemented in the contextcontaining the Context Control object. The returned object list con-tains 2 bytes per object: the object class followed by the object number.For example, if a context contains three objects (number 1, the ContextControl object (02); number 3, an Analog Control object (07); and num-ber 6, another Analog Control object (07)), the data stored in theobject_list is:

01 02 03 07 06 07

The Context Control object is object number 01 in all contexts exceptthe Universal Context where it is number 02.8

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

CAL

Determining Product Capability

CAL contains many “hooks” in the Context/object data structure toallow a node to determine the function and capability of any othernode on the network. Information contained in the Node Controlobject and the Context Control objects can be used to build a com-plete profile of a product’s CAL capability. The IVs intended for thispurpose include:

Node Control objectproduct_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 ofinteroperability.

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

The context_list and object_list IVs are required; thus, it is always possible totell what functions a product contains. This allows intelligent nodes (PCs,controllers) to present a user with a list of available functions. It also allowsscenarios 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, whichare called the General Contexts: Universal, Time, Data Channel, and UserInterface. The Universal Context is required in every product: the otherthree are used across industry product groups.

Other Context specifications are developed by the CEBus IndustryCouncil (CIC) in industry-specific working groups. Context workinggroups exist for each major industry category, such as HVAC, Security,Lighting, Utilities, and so on. Each working group is made up of repre-sentatives from companies that have a business interest in the productcategory. The working group develops the Contexts. When completed,Contexts are reviewed by the Context Development Committee and

191

192 Chapter Seven

submitted for ballot to all members of the CIC. Context specificationsare available from the CIC by industry group.

Messages: Object CommunicationsCAL messages are generated by objects via the CAL Interpreter or theobject’s application code. Objects communicate with other objects bysetting or reading their IVs. The message portion of the packet is for-mally known as the Application Layer Service Data Unit (ASDU).There are two types of ASDU: The command message and the responsemessage. The command message is sent to a device to perform anaction such as setting or reading the value of an IV. If a commandmessage is sent that generates a return value (such as reading an IV), aresponse 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 IVarguments. 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 tunerto 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 IVto the value given as an argument; the IV is the current_value (43 hex); theF5 token separates the IV label from the argument; and the argument isthe number 15 represented in ASCII. Because the current_value is anumeric data type, the argument is numeric, and numbers are transmit-ted as ASCII characters (remember?) 1, 5.

Message Address The context ID object # pair forms the desti-nation object address for the message. It identifies a particular object in

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

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

CAL

a particular context in the product. The context ID is made up oftwo parts. Its syntax is

<context ID> = [<context number>] <context class>

The first part of the context ID is an optional context number. Each con-text in a product is numbered because there may be more than oneinstance of the same context class in a product. The number is only usedif there is more than one context of the same class in the product. In theprevious tuner example, the Context number is omitted.

Context class values run from 00…9E hex. Context number values runfrom A0…DE hex. The context number DE is reserved to indicate the mes-sage should be applied to all contexts of the class in the device. For exam-ple, a context ID of DE 10 indicates that the message is addressed to allAudio Amplifier Contexts (Context class 10) in the device.

Context class values 90…9E are reserved for custom Contexts. Manufac-turers may create unique Contexts for a particular product by assigningthe Context a class number in the range 90…9E.

The object number is the sequential number of the object in theContext. 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 allobjects 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 themessage 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 anexplicit-invoke APDU, regardless of the command message. The returned

193

FROM addressNPDUheader

APDUheader

CAL message

<context ID><object#><method>[<IV>[<arguments>]]

12 03 45 43 F5 31 35

Figure 7.17Syntax of CAL mes-sage portion of pack-et. The example mes-sage is for the TuningContext (12), Chan-nel object (03), to setvalue (setValue 45) ofthe current_positionIV (43) to 15.

194 Chapter Seven

response always uses the Result APDU (APDU type 010). The responsemay contain information returned to a node as the result of a com-mand message.

The general syntax for the response ASDU is

<status token> [<returned data>]

The status token is a 1-byte indicator of the type of response, andthe returned data is any data returned as a result of the commandmessage. 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 com-

mand message was executed successfully, or a command with a booleanexpression evaluated to true. If the method in the command messagedoes not generate a returned value (such as a setON, or increment), onlythe COMPLETED token is returned. If the command message readsthe value of an IV (using getValue, getArray, and the like), the returnedvalue follows the COMPLETED token.

If the command message contains an if, do, or while method followedby a boolean expression, the expression evaluation will always generate aresponse byte, in addition to any response generated as a result of therest of the message. If the boolean expression evaluates true, a COM-PLETED token will be returned. If the true evaluation also causes amessage to be executed successfully, the response contains two COM-PLETED 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 objectis a numeric data type and currently has the value 67. A command toread the IV is received (using explicit_invoke APDU service):

getValue ‘C’

If the message is executed successfully, the response is:

<COMPLETED> 36 37

or

FE 36 37

However, if the command is:

if (‘C’ <GT> 0) BEGIN getValue ‘C’ END

CAL

then the returned response is:

<COMPLETED> <COMPLETED> 36 37

or

FE FE 36 37

The first FE indicates the boolean expression was true; the second FEindicates the getValue executed successfully.

The FALSE token (FC) is returned if the received command mes-sage contains a boolean expression that evaluates to false and, therefore,the message is not executed. For example, if the following message wereexecuted (given the same IV value of 67):

if (‘C’ <LT> 0) BEGIN getValue ‘C’ END

the returned result would be just FC, indicating a false result from theboolean expression.

The ERROR token (FD) is returned if the received command mes-sage is not executed by the CAL Interpreter. The ERROR token isalways 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 to13, 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 Interpreteron one or more IVs in an object. A method identifier is a single bytevalue (in the range 40 to 7E hex) that is followed by one or more argu-ments separated by the DELIMITER token. Each method operateson a specific IV data type.

Method Table The following table lists all of the CAL methods inorder of their hex value. Each entry contains the method name, theargument list, and the data types of the IV on which the method oper-ates. This is followed by a brief description of the method operation.

195

196 Chapter Seven

Methods whose ID is underlined, must be implemented if an objectcontains an IV on which the method can operate. The following sym-bols 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 Operates on:

METHOD ARGUMENTS B N C D

40 nop

No operation

41 setOFF IV

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 defaultoffset 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 theobject’s default_value IV.

46 setArray IV [offset] data

Stores data bytes into a data IV starting at an offset number of bytes. The defaultoffset 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.

CAL

Data types

Hex Operates on:


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 IVlabel or a value. The data type of IV and argument must be the same. Returns 1 (31hex) 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 thesame.

4F report IV

Initiates a reporting message from an object regardless of any predefined reporting_condi-tion 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 isterminated and execution continues after the END token. If value is given, all pars-ing 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 mustbe 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 thegroup address).

55 disinherit IV [ value]

Used to disinherit a value from a resource IV. IV must be the group address IV or a datachannel IV. value is a group address or data channel number that has previously beeninherited.

56 if boolean-expr BEGIN message list

[ELSE message list] END

197

198 Chapter Seven

Data types

Hex Operates on:


Used for the conditional execution of message list based on the result of boolean-expr. message list can contain any message that is valid for the object. boolean-expr 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 occurprior to testing boolean-expr. Execution of message list will terminate whenboolean-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 executingmessage list. Execution of messages will terminate when boolean-expr evaluatesfalse.

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. Copiesargument to IV in the same object or in context IDobject # 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 toparse and execute all methods. The methods in the previous table whoseID is underlined must be implemented if an object used in the productcontains an IV on which the method can operate. The following rulesmust be followed.

If an implemented object contains a boolean IV, then theinterpreter must be able to execute the setON, setOFF, setValue, andgetValue methods on that IV.

If an implemented object contains a numeric or string IV, then theinterpreter must be able to execute the getValue and setValuemethod on that IV.

If the object contains a data IV, the interpreter must be able toexecute the setArray and getArray method on that IV.

CAL

If an object contains an IV that is a CEBus resource (address, datachannel), the interpreter must be able to execute the inherit,disinherit, and if methods on the IV, in addition to whatever othermethod is appropriate for the IV data type.

In practice, almost all operations required of objects can be performedby using the basic set of required methods (setOFF, setON, getValue, set-Value, getArray, setArray, if, and inherit/disinherit). If a method is usedon an object and it is not supported, an error response (unknownmethod) 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 theplace of a method. A macro means the same in CAL as in most program-ming environments; it identifies a predetermined action or group ofactions performed in place of using or sending a list of those actions. InCAL, a macro defines a predetermined set of messages to be performedon or by the receiving object. Macros are defined in the CAL specifica-tion for some very common operations and are additionally defined insome context documents. In each case, the macro performs an operationthat is so common that defining a macro identifier makes sense.

Like a method, a macro identifier may take an argument. The bestexample of the use of a macro argument is in the address configurationalgorithms described later in this chapter.

Message Generation

Binding implies a message exchange between the bound objects. Objectsoriginate messages to other objects in one of two ways: the object’s asso-ciated application code generates a message, or the object’s reporting con-dition IVs cause the CAL Interpreter to generate a message automatically(Figure 7.18). The former is called an application message: the latter iscalled a reporting message.

Reporting Message Generation The reporting message capability ofCAL is the most common way to accomplish object binding. Wheneverthe value of the desired IV changes in a predetermined way (increases,decreases, becomes true, and so on), the CAL Interpreter sends a messageto another device (or group of devices) to update the value of a “target” IVat a Context/object address.

The advantage of using reporting is that it can be preprogrammedin network output objects because the destination Context/object is

199

200 Chapter Seven

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 outputand 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 asa group by the CAL Interpreter to determine when and where to send amessage to another node. Their function is illustrated in Figure 7.19.

Report_condition: A data variable containing a boolean expressiondescribing a condition in the object to test to determine whether areport message should be sent. The expression uses standard CALboolean expression syntax.

Report_address: A data variable containing the node and systemaddress of the destination device.

Report_header: A data variable containing the CAL message tosend to the destination device (less the current_value argument).The message contains the Context, object, method, and IV. The IVargument is appended from the current_value of the object.

Previous_value: The value of the current_value when the last messagewas generated. It is the same data type as current_value. Used by theCAL 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, andreport_header must be set to valid values by manually coding them orsending messages to the object to set the IVs.

Figure 7.18Messages originatefrom the CAL Inter-preter using thereporting IVs or anobject, or from theobject’s applicationcode.

CAL

Whenever report_condition evaluates true, the message in thereport_header (with the object’s current_value appended) is sent to the address in report_address to update the value of a “target” IV. Thereport_header contains the target Context/object address.

Using the Report_condition IV The report_condition IV is used bythe CAL interpreter to determine whether a report message should be sent. If report_condition contains a valid CAL boolean expression ofthe form:

<relational expression> [AND/OR/XOR <relational expression>]

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

201

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

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

202 Chapter Seven

1. It generates a message using the report_header and report_address IVto form the message (Figure 7.19).

2. It replaces the previous_value IV with the value of thecurrent_value IV.

CAL appends the current_value IV to the report_header and sends the mes-sage to the report_address. A report will not be generated again until theexpression evaluates from false to true (that is, it must first transitionfrom true to false and then false to true).

The form of the relational expression is:

(IV or <value>) GT/GTE/LT/LTE/EQ/NEQ/DELTA (IV or <value>)

The IV(s) used in the relational expression must be in the object con-taining the expression, and the value must be the same data type asthe IV type. The boolean expression always evaluates to true or false.The implemented length of the report_condition IV must hold the largestboolean 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 thesecond example) so they will not be parsed as an IV label.

The DELTA operator evaluates as “changed by” and tests whetheran IV has changed by a value amount. The test is performed by com-paring the IV used in the expression to the previous_value IV. For exam-ple, the expression:

‘C’ <DELTA> 25

is evaluated as:

ABS(‘C’ - previous_value) > 25

To test an IV for ANY change since the last report, the comparisonvalue of 0 (zero) is used. For example,

‘C’ <DELTA> 0

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

CAL

Because reporting messages originate in the CAL Interpreter, theInterpreter usually uses implicit_invoke APDU service as a reply is notexpected. The report message NPDU is usually set to all media, direc-tory routing. The NPDU and DLPDU services are chosen by theimplementer. There are no required protocol services for messagereporting.

Using the Report_header IV The report_header IV contains a validmessage header in the form:

<context ID> <object #> setValue [ IV F5h [LITERAL]]

When the message is sent, the current_value IV of the object is appendedto the header bytes following the F5 token. If current_value is a characterdata type, the header ends in the LITERAL token, and the charactercontents of current_value are appended to the LITERAL. The contextand object must be a valid Context/object address in the target device orgroup of devices. The method should be setValue,12 and the IV should bethe 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 cur-rent_value IV is a character string, the [IV F5 LITERAL] constructshould be used.

For example, if the reporting object’s current_value IV ‘C’ contains anumeric 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 lengthanticipated for a message header.

Using the Report_address IV The contents of report_address IV deter-mine whether reporting is “on” or “armed” in the object. If the IV con-tains a valid 4-byte target device system and node address, reporting ison. If the report_address is set to zero (0) or null,13 reporting is turned offand no reports will be generated. The address is stored in the order:

203

12Because 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 isalways used in a report message.13Using setArray A DELIMITER DELIMITER DATA 31 ESCAPE 00. Thisshould 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. Thesystem address must be a non-zero address. A system address of FFFFimplies that the node should obtain the system address from its own sys-tem_address IV in the Node Control object. The data length for thereport_address IV should always be 4 bytes.

Implementation ExampleFigure 7.20 shows an example implementation of a Context/object datastructure in two simple products: an outside temperature sensor deviceand part of a thermostat. The example illustrates the use of objectbinding using the reporting IVs in the temperature sensor. The outsidetemperature sensor device contains the data structure for object 03, theOutside Temperature object, of the Environmental Sensor Context (41).The application code updates the current_value IV from the A/D con-verter. The report_condition C delta 1 will cause the CAL Interpreterto send a message any time the current_value changes by 1 as a result ofa change in temperature. The CAL interpreter checks the current_valueagainst the previous_value IV. When they differ by 1 degree, the inter-preter generates a new message to the report_address of FFFF, 0000 (thenode’s system address, the broadcast node address). The message is tocontext 43, object 03 to update the value of its current_value to the mostrecent temperature value.

The message is acted on by any node in the house containing the Envi-ronmental Status Context/Outside Temperature object, such as the livingroom television and the heat pump thermostat. The application code inthe thermostat updates the outside temperature display from thecurrent_value. Note that in both products, only the objects needed for the application are used, and only the IVs needed are used. Binding via thebroadcast node address makes field installation of products a trivial task.

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

CAL

addresses, group addresses, system addresses, and data channels. Every CEBusnode must be capable of handling resource allocation. The basic rules forresource 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 theresource is not available. If no node responds, the resource isavailable 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 theresource is in use).

Address Resources and Address Allocation

The most common resource allocation task is address allocation. Eachnode on the house network must have the same system address, and a

205

Figure 7.20Example implementa-tion of a temperaturesensor device show-ing the use of theEnvironmental SensorContext.

206 Chapter Seven

unique node address.14 CAL provides sufficient resource allocation com-mands to acquire address resources over the network.

The primary technique used for resource allocation is hailing. Hailingis a request, to all nodes in an address subset, for a desired resource. Thegeneral form of the hail is:

if (<resource IV> EQ <requested resource>) BEGIN exit ‘8’ END

where resource IV is the IV containing the desired resource, andrequested resource is the value of the resource desired. If the expres-sion 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 net-work, and is not available.

The message is sent using conditional_invoke service to theContext/object containing the resource IV. Only the node containingthe resource will respond if the expression evaluates true. If it evaluatesfalse, no response is generated.

If no response is received (in the 1.5 second MT Wait Time), therequest message is resent. If a reply is not received after the secondrequest, the resource is available. For example, to hail for a node addressof 0021, the following message is sent to the broadcast node address(0000), the Universal Context, and the Node Control object because itcontains the node_address IV:

if (‘a’ EQ 0021) BEGIN exit ‘8’ END15

The message is sent using the conditional_invoke APDU service, so that onlynodes that evaluate the expression as true will generate a response message.

This hailing message format is used to acquire other resources such asdata channels. The following example hails for data channel 17h. It is

14More than one system address can be used in a house or apartment. In practice, a differ-ent system address may be used for each medium used in the home, depending on whatorder media are used and when Routers are installed. However, to keep the explanation ofaddress acquisition and address propagation simple, this book assumes that there is onlyone system address used in the house.15This is an easier to read message format. The actual form of the message is:

if ‘a’ EQ DATA 32 ESCAPE 00 21 BEGIN exit 38END

or

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

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 hailedfor is implied by the destination address of the message. Only the mes-sage exit ‘8’ needs to be sent to the node address hailed for. In the previ-ous example of a hail for node address 0021, the simplified hail wouldsend the message to the current system address, node address 0021, ratherthan to the broadcast node address. If a node already has the nodeaddress 0021, then sending the message to that address is equivalent tobroadcasting 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 mustacquire a valid system and node address. The node must acquire the samesystem address as other nodes in the house, and a unique node address. Ifit is the first device installed in the home, it must acquire a unique sys-tem address, different from the system address that is being used byneighboring houses or apartments. As each new device is added, the newdevice must acquire the same system address as the first node, and a nodeaddress not used by any node previously installed (at the system address).

How not to Acquire Addresses The standard does not specificallyrule out letting a user pick and set a product address.

207

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

208 Chapter Seven

However, allowing the homeowner to set product network address-es using DIP switches or rotary switches—even if they could repre-sent all 65,000 system and node addresses—simply does not work.Consumers are not generally capable of understanding addressingconcepts and keeping track of what device has what address. If devicesare addressed incorrectly, troubleshooting the network is beyond the capability of most consumers, even for those with a technicalbackground.

The solution is to require devices to acquire their own addresses usingself-acquisition or directed acquisition techniques. The CAL portion of thestandard details an address acquisition and propagation algorithm thatwill 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 notdescribe how the algorithm is initiated or how any user interaction isperformed. The algorithm does not rule out the use of more sophisticat-ed manufacturer-dependent algorithms.

Address Self-Acquisition

Self-acquisition of a system and node address means that the installednode must be capable of negotiating for a new or existing system addressand a new node address. The process is different for the first nodeinstalled in a new system versus a node installed in an existing system.

Getting That First System Address The first node installed in thehome must acquire a unique system address. From a resource allocationstandpoint, the task is straightforward.

First, the node picks a random system address to try from the rangeof possible 16-bit address values. Once picked, the node hails for theresource. The message uses the selected system address and the broadcastnode address (0000) as the destination address,17 to the Universal Context,Node Control object using explicit_invoke service:

[00 01] exit ‘8’

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

CAL

If any nodes on the global network have the selected system address andreceive the message, they will respond.18 If no responses are heard, therequesting node can use the system address and set its system_address IV(after repeating the request one or more times to ensure the message gotthrough). If a response is heard, the node must pick another systemaddress and try again. The process continues until an address is pickedthat produces no response. After the node acquires a system address, itcan set its node_address IV to any valid node address value. No hailing isnecessary because there are no other nodes at the new system address.

How this process is initiated—the user interface used—is up to themanufacturer, and depends mostly on the user interface available on thenode. 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 selectedby an IR remote.

When nodes other than the first node are installed, the process is alittle more complex. New nodes need to acquire the system address ofthe already installed node(s), and a unique node address. To accomplishthis, one or more existing nodes must be able to “propagate” their systemaddress to the new node. This must be accomplished without interferingwith possible new nodes in a neighbors house.

The Address Propagation Algorithm The algorithm to propagate asystem address uses the address resource allocation IVs in the Node Con-trol object (configured, config_master, setup, and user_feedback). The algo-rithm works by establishing two classes of “addressing” nodes: the AddressConfiguration Master node and the Address Configuration Slave node.The Master node already has a valid system and node address—its config-ured IV is TRUE. It acquired its system and node address either by hailingor by being configured by another node. The Slave does not have anaddress and needs to be configured. Any CEBus node can be either aMaster or a Slave.19 The algorithm is illustrated in Figure 7.21.

The process assumes that some action starts the algorithm in the Mas-ter and Slave device. This could be a user pressing a button, or makingan onscreen menu selection, or by using a controller device such as ahand-held remote. The user feedback events in the algorithm assumesome notification to the user or controller.

209

18Because the hail was sent using explicit_invoke service, many nodes may respond. Thehailing node can discard all but the first response.19The software to perform address propagation is not required in a node if another meansis provided to address the node.

210 Chapter Seven

The first step in the algorithm is for the Master node to acquire theconfig_master resource. The config_master IV is used as a networkwideflag to indicate—to the network—that a node is propagating its housecode. Only one node on a global network can have config_master TRUEat a time. This prevents two neighboring house codes from performinghouse code propagation at the same time, which would cause a Slavedevice to get the wrong system address. This is only one of several safe-guards built into the algorithm to prevent inadvertent propagation.

The Master hails for config_master using a macro method to simplifythe message structure.20 The message is sent to the broadcast system andto 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

Figure 7.21The address propa-gation algorithmillustrated betweentwo nodes. A usermust initiate thealgorithm in bothnodes using someinterface provided bythe manufacturer.

20Almost all the address configuration messages have been standardized into a set of pre-defined macro instructions because every node must be able to perform most of themacros.

CAL

The hail is performed twice, with a minimum 2-second wait between eachtry. If the hail was successful—no responses were received—the Master setsits config_master IV to TRUE and notifies the user that propagation cancontinue. When a Master has config_master TRUE, it will also receive mes-sages addressed to system address 8000. Once config_master is acquired, it staysset for 5 minutes (recommended). This gives the user time to initiate theSlave algorithm.

If, during the 2-second wait following transmission of the M1 macromessages, an M5 macro message is received, it means that another nodealready has config_master set. The Master provides a negative notificationto the user that propagation is not possible now (user_feedback IV set to3). 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, andsets system_addr to 8000. System address 8000 is reserved exclusively forMaster/Slave communications during address configuration. The Slavethen hails for a temporary node address using system address 8000, nodeaddress 0100. When acquired, the Slave broadcasts macro M2 (meaning Iam setup and ready) to address 8000,0000.

When received by the Master, the Master immediately transmits macroM3 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 byone. M3 is equivalent to [00 01] increment setup.

After the 5-second wait, the master then transmits macro M4 toaddress 8000,NA (using explicit_invoke service). This macro causes theSlave node to complete the propagation process. The Slave checkswhether the setup IV has a value of 2. If it does, it will set its system_addrto the source system address field of the received message—the systemaddress of the Master—and hail for a new node address. When a nodeaddress is acquired, configured IV is set to TRUE, and the user is notifiedthe process completed successfully (user_feedback set to 2). The Slavereturns a reply APDU with a Results Complete ASDU. The reply mes-sage source address has the Slave’s new node address. This may be usefulto the Master.

If the setup IV is anything other than 2 when M4 is received by theSlave, it means that two Masters (somehow) are attempting to propagate,and the Slave ignores the message and notifies the user that propagationdid not work (user_feedback 3).

Directed Address Acquisition Address configuration can also beperformed by a third-party device that manages node addresses. Many

211

212 Chapter Seven

variations of address configuration are possible if enough intelligence isavailable 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 seri-al number (stored in the serial_# IV) is known at installation, this valuecan be used to directly set the system and node address using a messageto the broadcast system and node addresses (0000, 0000):

[00 01] if (serial_# EQ <known serial number>) setArray ‘h’ <systemaddress>

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 <DATA> <serial number length> <ESCAPE> <serial number>

This is the syntax for a user-defined message. The serial number is trans-mitted as data to the Universal Context. This might happen when thedevice is unconfigured and powers up.

A controller device can also cause all nodes that have not been config-ured to return their serial numbers by broadcasting the following mes-sage to (0000, 0000):

[00 01] if (configured EQ FALSE) getValue serial_#

All nodes that are on the network and not configured will return theirserial number. The nodes can then be individually located by broadcast-ing the message:

[00 01] if (serial_# EQ <specific # >) setValue user_feedback ‘1’

This causes something on the device to indicate that it should be config-ured. The user can then perform some action, such as causing it to enterthe 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 theproduct_class IV.

21The CEBus Industry Council will assist manufacturers in selecting a serial numberrange that is not used by other manufacturers. CIC maintains a list of assigned serialnumber prefixes.

CAL

The CAL InterpreterThe CAL Interpreter is the element of the Application layer responsiblefor parsing and executing most ASDUs. The Interpreter performs twotasks: it parses and acts on incoming messages, and it generates any mes-sages 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 performthese tasks, the most common is a simple interpreter. An interpreter canhandle the widest class of received messages and generalize method exe-cution and object access. An interpreter must have some data structurethat represents the implemented Contexts, objects, and IVs, so that IVscan be read, written, and tested. The data structure must also be accessi-ble from the device application software.

The parsing is straightforward. The CAL Interpreter looks at theincoming message, determines whether it can be performed based onwhat 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 messagemust be generated.

An example Context/object data structure is shown in Figure 7.23.This example shows the data structures implemented as a series oflinked lists. The Context list contains one list element per Context. The

213

Figure 7.22General parsingscheme for a typicalCAL message. If anyof the conditions fail,an error response isreturned.

214 Chapter Seven

Context element contains a list of implemented objects and a pointer tothe object IV data structure. The object structure contains a pointer tothe 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 andcall the Interpreter. In either case, execution timing requirements mustbe carefully watched. The CAL Interpreter must keep up with incomingmessages. Application routines need to keep up with changing IV valuesand the application requirements.

Simple CAL Interpreters that are capable of only the minimumrequirements have been written in small microcontrollers in less than5K bytes of code. A full CAL Interpreter that is capable of executing themajority of parsing and reporting requirements will probably requirebetween 10K and 20K bytes.

Transporting Non-CAL Messages

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

Figure 7.23Example implementa-tion of CAL Contextdata structure and itsinterface to the appli-cation I/O routines.

CAL

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

Generic CAL (ANSI/EIA-721)In 1997, the EIA began a separate effort to “spin-off” the CAL languagefrom the CEBus protocol. The EIA, as well as the CEBus Committee, hadreceived many requests for information about using CAL with otherprotocols. Also, because the HomePnP specification (see Chapter 9) hadadopted CAL as an interoperability language, and because HomePnPwas intended to be used with any transport protocol, there was a defi-nite need for a generic version of CAL that was not tied to the specificsof 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 thenumber EIA-721 and named Generic CAL.

The goal of Generic CAL is to provide a protocol-independent lan-guage specification that can be adapted (through a “protocol adapter”) toany protocol capable of operating reliably in a home and providing two-way message transport.

The network Adapter layer takes the place of the Message TransferElement in CEBus and provides the interface between the Generic CALInterpreter and the lower levels of the protocol, implementing thereceive and send message transfer interface.

Differences between Generic and CEBus CAL

EIA-721 is nearly identical to CEBus CAL except for items in the lan-guage that were designed around the lower-level protocol assumptions.The major difference is in how Generic CAL and CEBus CAL handleaddressing and the network address space. Other differences include tim-ing and quality-of-service issues.

215

216 Chapter Seven

Addressing CAL always assumes the CEBus standard address space of a16-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 for-mats: a Short Device Address and a Long Device Address. The address bytesare grouped into 16-bit words named addr1, addr2, addr3, addr4, addr5,addr6, addr7, and addr8. The first two words, addr1 and addr2, appear inboth length formats. Thus, the Short Device Address consists of 4 bytes(two 16-bit words). The long format may include one to six additionalwords: 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. Thetwo-part address format of EIA-600 is appropriate for network mediathat span more than one logical area, such as a house, office, or apart-ment. In this case, the address is composed of two components: areaaddress and unit address. Each logical area that shares a medium, such aspower line or radio, would be assigned a unique area address (corre-sponding to the system address in EIA-600), while devices sharing a logi-cal network within an area are assigned unique unit addresses. For net-works that accommodate multiple media, some of which span morethan one area, this two-part addressing scheme is suggested for allmedia to facilitate internetworking.

Figure 7.24Generic CAL interfaceto a non-CEBus pro-tocol stack.

CAL

A device can determine its unit address and area address, using thesame address configuration algorithms listed earlier for CEBus CAL.

The long format for device addresses is appropriate when implement-ing Generic CAL on some protocols, such as the Internet Protocol. Ver-sion 6 of the Internet Protocol specifies 128 bits (16 bytes) per address.

Group addresses, if implemented, can also be determined statically ordynamically. Membership in a group is determined by the user. Forinstance, a bank of lights in a room may always be turned on or offtogether. By selecting a group address and asking each of the lights tojoin the group, a single transmission can be used to manipulate all ofthe lights together.

Timing Issues CEBus CAL established several timing restrictions onthe interface between the MT Element and the CAL Interpreter Ele-ment (see Basic Service Details section of Chap. 7). These timing restric-tions, such as explicit_invoke response times, were designed assuming aCEBus network, and will have to be adjusted (or eliminated) for othernon-CEBus networks or mixed protocol networks.

Quality-of-Service Issues CEBus CAL assumed a certain quality ofservice provided by the lower protocol layers, such as DL Acknowledgedservice. When implementing Generic CAL, it may be necessary or desir-able to implement a way for the CAL Interpreter to know the quality-of-service capability of the lower protocol layers. This information can betransferred to the CAL Interpreter Element via Layer System Manage-ment (or the equivalent).

The following quality-of-service factors may effect the operation ofthe Generic CAL interpreter and should be made available from thelower protocol layers:

Transport layerSegmentation allowed/disallowedMaximum message sizeEnd-to-end error managementNetwork layer

Flood versus directory routing capabilityMedia supportedMedia restrictions for particular message types

Data Link layerSupport for unacknowledged retries

217

218 Chapter Seven

Support for immediate acknowledgment with up to n retriesSupport for packet acknowledgment with up to n retriesWhether source address may be omittedWhether packet priority levels are supportedWhether specific service classes are supported

Interoperability andHomePnP

8CHAPTER 8


220 Chapter Eight

Having a broad range of truly interoperable, out-of-the-box, plug-and-play products has always been a “holy grail” of the home automationindustry. It would stimulate a wealth of new products and allow homeautomation to reach the consumer on a large scale. But despite the devel-opment of new “interoperable” network technology and standards overthe past few years, that goal remains elusive. A big problem has been alack 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: communi-cations, applications, and plug-and-play. Communications interoperabili-ty implies that products can successfully communicate with eachother—send information from product A to product B—using a com-mon protocol and physical medium. Network protocols such as Eche-lon’s LonTalk, the CEBus protocol, the X-10 message protocol, and RS-232all provide communications interoperability. Application interoperabili-ty, requires products to use a common “language” at the application level.CEBus’s CAL is the best example. CAL lets products understand whatother products are “saying.” But manufacturers have already learned thehard way that even with the same communications protocol and appli-cation language, unless product applications are specifically designed towork together and are installed correctly, interoperation between prod-ucts from different manufacturers is unlikely. It requires plug-and-playinteroperability, meaning that products from different manufacturers, indifferent product categories, can be purchased, connected, and self-con-figured, so that they operate together in a way that can only be achievedby predefined cooperative interaction.

Several years ago, a group of companies set out to write a completespecification about how consumer products should “behave” together toachieve plug-and-play interoperability. Intended as a consensus agreementbetween manufacturers, the HomePnP (Home Plug-n-Play) specificationwas finished in September 1997. The specification defines how networkedproducts can achieve a plug-and-play level of interoperability regardless ofthe communications protocol used (CEBus, IEEE-1394, TCP/IP, and so on).

HomePnP OverviewThe HomePnP specification defines exactly what product manufactur-ers need to successfully make network products that will work togetherout of the box.

Interoperability and HomePnP

The above Figure 8.1 shows the domain of the specification in terms oftraditional protocol design. The specification builds on the commonapplication language (CAL) of the CEBus standard by defining a com-plete interoperable product function data structure, and a set of interop-erability guidelines for the proper use of those data structures. CAL wasused as a basis for HomePnP because it is a general, flexible, object-ori-ented language designed for consumer product operation and because italready had the mechanism for network management and productinteroperation.

The Context data structures are defined in a set of subsystem defini-tions and represent tremendous industry consensus-building regardingthe operation of subsystem for security, lighting, environmental, energymanagement, utility, computer, and entertainment applications. EachCAL 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 behav-ior necessary to make products that correctly use the subsystem models.The guidelines also define procedures for difficult plug-and-play prob-lems such as self-configuration, resource allocation and conflict resolu-tion, resource subscription, product zoning, locking, and message scopeand security.

None of the components of HomePnP rely on any particular Trans-port protocol capability. To make implementation on different trans-ports easier, a new transport-independent version of the CEBus CALlanguage (referred to as Generic CAL) was defined in EIA-739. HomeP-

221

Figure 8.1Domain of theHomePnP Specifica-tion relative to vari-ous Transport pro-tocols.

222 Chapter Eight

nP allows manufacturers to use a Single-Application protocol and toseparately select an independent Transport protocol appropriate forthe subsystem.

Some New IdeasHomePnP established several new techniques and principles to achieveits 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 begrouped into functional subsystems (lighting, environmental, entertain-ment, and so on) and that communications between products in a sub-system and between subsystems is hierarchical. Each subsystem is speci-fied by a set of context data structures that define intersubsystemcommunications—messages between peer subsystems in the home—and intrasubsystem communications—communications betweendevices or device components within a subsystem (Figure 8.2). Mostintersubsystem communications are in the form of status and request

Figure 8.2Subsystem interoper-ability is defined bytwo types of contextcommunications:intersubsystem(between differentsubsystems) and intra-subsystem (within thesame subsystem).


messages; status information is broadcast to indicate the general status ofthe subsystem (the security system arming status or the heating/coolingsettings), or to request a subsystem operation (home theater mode or alighting scene).

Each subsystem context represents a product or subsystem functionand is typically dedicated to either providing or accepting statusinformation or commands. During installation configuration, eachcontext acquires an identification number ID (similar to a networkaddress) to uniquely identify and bind its function on the local homenetwork.

Communications between subsystems rely on loose coupling betweenContexts. Status and requests, in the form of state vectors, are broadcast tonetwork functions (Contexts), not products, by using Context ID num-bers as a form of function address. The majority of HomePnP deals withintersubsystem (loose coupled) communications, which greatly simplifiesproduct installation.

Intrasubsystem communication is command/status oriented (set theVCR to play, TV to channel 13, the temperature is 73) and provides the details necessary to supply subsystem status or implement subsystemrequests. Communications between functions within a subsystem typi-cally rely on tight coupling or binding. Status and requests are directed tofunctions in specific products or network addresses.

The inter- and intrasubsystem context design reflects the typical phys-ical nature of how product categories are organized in the home. Figure8.3 illustrates a typical portion of an A/V subsystem and an HVAC sub-system. A/V products use a local 1394 bus for intrasubsystem communi-

223

HVAC equip.

73

Thermostat

TPIntrasubsystem Messages Intrasubsystem Messages

Intrasubsystem Messages

PL

TV

VCR

1394

Figure 8.3Typical subsystem(inter- and intra-)communicationsoften reflect thephysical “clustering”of devices in thehome.

224 Chapter Eight

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

State Vectors

To increase the efficiency of subsystem communications, HomePnPdeveloped a new form of CAL message called the state vector: a hierar-chical string of data providing a synopsis of a subsystem status orrequested operation. The hierarchical vector data is abstracted from thedetails of the subsystem with the first element (one or more bytes) ofthe string being the most significant data, the second element modify-ing the first, and so on (Figure 8.4). Listening devices only parse to thelevel of detail they can act on.

Not all HomePnP state vectors (or messages) are strictly between twosubsystems or functions within subsystems. Some information is net-work “global,” applicable to all subsystems. One of the best examples of aglobal state vector is used to represent the house mode—the overall “activ-ity” or state of the house. The first element of the house-mode vectordefines the house occupancy (occupied, unoccupied, or uncertain), thesecond element defines probability (certain, probable), the remainingthree elements are house state modifiers that add increasing details tothe actual or desired state of the house (occupancy activity, remainingtime unoccupied, and so on).

Any device can contain Contexts to generate or receive the housemode state vector and the information can be used to change the oper-ating mode of each subsystem.

Figure 8.4HomePnP state vec-tor design. The statevector (sv) elementsare hierarchical; thefirst conveying toplevel information, thesecond modifyingthe first, etc.


Configuration

A big contribution of the HomePnP specification is the details of prod-uct self-configuration. HomePnP product configuration requires a lotmore than just obtaining a valid network address. It covers the proce-dures for dynamic loose (Context number) binding, manual loose bind-ing, resource allocation, resource subscription, conflict resolution, groupaddressing (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, dis-play, storage). These resources must be allocated so that there is no con-flict between two providers (such as two devices providing the time) andeach is uniquely identified. Resource users must be able to “subscribe” toor locate and receive the type of resource information desired (such asthe time from the DSS receiver). Both procedures use dynamic ContextID generation during installation to differentiate resources and to allowresource 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 securitycommensurate with the protection needed and the complexitythat can be afforded by an application.

Scheduling—A common way to express device operation schedulesso they use a similar data structure and can be edited in a uniformway.

Locking—The capability to “lock” a device function by one productto prevent interference by other products during an operation orinteraction.

User Interface—A common user interface model so that users see aconsistent interface with the subsystems in the home, andapplications can take advantage of any available interface.

225


Product Development

9CHAPTER 9


228 Chapter Nine

This chapter builds on the information presented in the previous chap-ters to outline how to create CEBus-compliant products. An exampleproduct development process is given for a typical networked product,emphasizing the requirements for network interoperation with otherproducts.

A CEBus-compliant product developer has complete freedom toimplement the necessary CEBus network interface in any way that thedeveloper chooses. Products may be developed using any combinationof hardware and software, designed from “scratch” or purchased fromother vendors. This implementation freedom gives the designer plentyof room to innovate—which is intentional—but also provides the free-dom to make numerous mistakes. Care must be taken to ensure correctimplementation of the standard and to correctly use network resources.

This chapter should clarify many of the product design decisionsnecessary to successfully make networked products.

Design Considerations forNetworked ProductsMany of the problems encountered by developers of new CEBus-compli-ant products are not technical but typically deal with proper networkoperation. While the problems associated with making a product com-municate over a residential network are not trivial, they are straightfor-ward. The CEBus physical layers and protocol solve the basic problem ofgetting two products on the network to communicate. The more diffi-cult problem is understanding what to do with the network capability:what resources to use in other products; what products to control; andwhat resources to make available to other products.

The designer of a networked interoperable product, especially a con-sumer product, must make several decisions above and beyond the tradi-tional ones of cost/feature trade-offs, market size, and service. Thedesigner must consider at least the following:

How the product will be used with other products: what resourcescan it use in other products, and what resources can it makeavailable to other products

Network installation issues: how customers or dealers will installthe product successfully

Product Development

Acquiring network addresses: Is the intelligence to do this in theproduct or is it assumed to be in another product?

Product security: preventing unauthorized “user” access to productdata or operation

The network medium to use must also be considered. Because thedesigner of CEBus products has a choice of at least five media, selectingthe best medium is a trade-off of medium availability, transceiver cost,installation ease, and power needs. The following sections consider someof these issues in more detail.

Security

Product security is a concern for any networked product. The designermust consider the implications of providing access to product informa-tion and control from other products and users, potentially in anotherhouse. This influences what functions in a product are accessible byContext implementation. For example, take the operation of a hypothet-ical CEBus-compliant Black and Decker iron. The iron uses the powerline as a network medium. While there is a CEBus Context that mightbe used to allow the iron to be controlled over the network (Context 72,Water Heating) its implementation in the iron is unlikely. This Contextwould allow the iron to be turned on and its temperature set by anotherproduct. If operated at the wrong time, even accidentally, this couldresult in a fire if the iron was unattended. From a practical viewpoint,there is little to be gained by controlling an iron from another productanyway. In reality, Black and Decker chose not to implement the heatingContext, but to implement the Security Control Context (63) in theproduct. This Context (Figure 9.1) contains an object (Partition Status)that will receive the arming state of any CEBus-compliant security sys-tem in the house. If the system is armed in the “away” mode—meaningthat the interior of the home is armed and no one is home—then it willbroadcast the state to all products containing Context 63. This will bereceived by the Context in the iron, and the iron can use this informationto turn off. That is, the iron will automatically turn off whenever thehouse is unoccupied; a more appropriate and safe use of the technology.

For more sensitive network transactions, such as setting the electricmeter rates, arming or disarming the security system, it is appropriate touse the message authentication algorithm described in Chapter 6. Thesoftware overhead of this algorithm is significant and the designer must

229

230 Chapter Nine

weigh the trade-offs of increased security verses potentially increasedcost. Another consideration of message security is the requirement thatthe transmitter of the message must have the necessary keys and encod-ing algorithm. This means that both the transmitting node and thereceiving node must be built by the same manufacturer, or the manu-facturers must agree (privately and secretly) on how the key informationis propagated at installation. While message authentication provides ahigh degree of security, its implementation carries a significant softwareburden and should be used only where warranted.

Addressing

A product manufacturer must decide how its products will acquire anetwork system and node address when installed. The need for anaddress is a new requirement for consumer products. Consumers are notfamiliar with the concept, technique, or the need. If address self-acquisi-tion is used, some means must be incorporated into the product tomake the product hail for a new system and node address, or to use theaddress propagation algorithm. This might be an onscreen display, a sep-arate button, or some other technique. Manufacturers are understand-ably reluctant to add a button or to switch to a product that may onlybe used once when the product is installed. They are more likely to useexisting user interface elements in some unique way. The trade-off ispotential consumer confusion versus cost savings. Whatever technique is used, it must be explained to the consumer and it must be easy forthe consumer to accomplish. Some form of user feedback to indicatewhen address acquisition was successful must also be provided.

Using directed acquisition is potentially simpler but requires that theuser already have, or purchase, a device to access and address the node.There is no standardized way—or industry-accepted way—to do directed

Figure 9.1Portion of SecurityPartition Control Con-text. The Partition Sta-tus object monitorsthe arming status ofany security system.

Product Development

acquisition. This may change as more manufacturers leverage off config-uration nodes from other manufacturers.

Interoperability

There are two general types of product interoperability to considerwhen developing a new product: intraproduct interoperability andinterproduct interoperability. The concept is illustrated in Figure 9.2.

The primary consideration of product designers is interproduct inter-operability, or interoperability across industry categories. This offers theconsumer the greatest potential gain in added convenience, safety, flexi-bility, and enhanced features. This type of interoperability is generallyconcerned with information to and from other products rather thanproduct control. Each Context group deals with interproduct communi-cations by providing one or more Contexts that specifically provide sta-tus and possibly control information to and from one or more contextsin other industry groups. This allows monitoring and control of productsubsystems on a whole-house basis.

Of secondary consideration is intraproduct interoperability, or inter-operability within a product category. This is the kind of operation thatmost manufacturers think of when they consider network operation.This deals with status and control from, for example, the thermostat tothe heating/cooling equipment, the light switch to the light, the securitysensor to the security panel, and so on. Each existing Context groupcontains the necessary Contexts to enable interoperation of almost all

231

Figure 9.2The basic model ofinter- and intraprod-uct category interop-erability.

232 Chapter Nine

types of equipment and/or functions within a product category. Thisallows the details of subsystem component operation to be handledwithin the subsystem, and high-level subsystem operation to be con-trolled and monitored by other product categories. Most Contexts in aproduct category are for intraproduct communications.

Partitioning of Processing TasksProduct designers must consider the software partitioning of the entireCEBus software “stack” from the low-level physical layer to the productapplication software, considering the processor time allocation require-ments of each layer (see Figure 9.3). The Data Link layer is obviously tim-ing intensive. It must keep up with the arrival and transmission of sym-bols at 100 s intervals on PL and RF, and must sample incoming symbolson TP, CX, and IR every 25 s. This process cannot be interrupted byapplication routines. If the application software is process intensive, it mayneed to be in its own dedicated microcontroller. If it is performing a sim-ple sensor task (monitoring a switch or temperature sensor), it can run inthe background when no other layers are processing. The CAL interpreterneeds to parse incoming messages fast enough to keep up with arrivingmessages and to handle reporting conditions within a reasonable periodof time. If the protocol and application are sharing the same microcon-troller, careful use must be made of interrupt processing to prevent theloss of incoming symbols, and to keep transmission timing of outgoingsymbols accurate. If the protocol software is divided between two or moreprocessors, then the optimum place for division is between the Data Linkand Network layers, and between CAL and the application.

If an application does not require fast processor response and requiresonly minimum application software overhead—a light switch or ther-mostat, for example—a single microcontroller can implement all soft-ware functions (Figure 9.4). The only additional IC required is a trans-ceiver (for PL or RF). An application that uses TP, IR, or CX might onlyneed the microcontroller and might rely on discrete components toimplement the transceiver function. The example of the light switch istypical of implementations in products that do not use a microcon-troller in their existing, stand-alone design. It must bear the highestoverhead for conversion to network operation. Existing microcontrollers,such as the Motorola 68HC705 series, can easily handle the protocol anda small application in such products.

Product Development

Products that already use a small microcontroller/processor maychoose to implement the upper layers of the protocol in the existingprocessor and add an inexpensive dedicated microcontroller (for exam-ple, 6805, 8051) to handle the Data Link layer (Figure 9.5). The DLL chipinterrupts the higher layers whenever a complete packet has been suc-cessfully received and needs processing. Likewise, the DLL chip can pro-vide an interrupt upon successful completion of packet transmission.The Intellon Corp. makes a special version of their PL transceiver chipthat integrates the DLL with the transceiver for a one-chip solution tothis implementation option.

233

Figure 9.3Typical partitioning ofthe protocol stack.The DLL is the mosttime-critical layer,while the applicationand I/O routines arepotentially the mostprocess intensive.

Figure 9.4A light switch is typi-cal of applicationsthat contain no exist-ing microcontroller.An added microcon-troller must imple-ment all protocol andapplication code.

234 Chapter Nine

Products that incorporate more complex microprocessors have theoption of implementing the whole software stack, including the DataLink layer, in the existing processor (Figure 9.6). If the processor is capa-ble of keeping up with 100 s interrupts, this becomes an attractiveimplementation because no additional microcontroller is required.

Creating CEBus Applications: AnOverviewThis section describes how to create a simple CEBus application. It illus-trates the design considerations discussed previously. The process con-sists of defining the needs of the application, the hardware to be used,and the control functions to be implemented. The following steps arestraightforward.

1. Design the basic operation of the product including hardwareand software requirements.

2. Determine what parts of the product should be accessible fromother devices on the network, considering the potential benefit vs.potential problems.

3. Determine what information (status, state, values) will be receivedfrom or sent to other products. What resources in other productswill be beneficial and add value, and what resources in theproduct under design will be made available to other products.

4. Choose a set of Contexts that best represents the function of theproduct, and that provide interoperability with other industrygroups.

Figure 9.5Products with an exist-ing microcontrollermay choose to imple-ment the higher-levellayers in the existingprocessor and add aData Link microcon-troller to handle thefast-response tasks ofthe DLL.

Product Development

5. Select the minimum working set of objects in each Contextnecessary to meet the basic operation, and provide information toother products.

6. Determine what output objects need to generate messages, and setthe IVs accordingly, using network broadcast whenever possible.

7. Test the model in a development system by observing behavior ofthe model while sending and receiving message with otherproducts.

8. Compile the Context data structure with the application codeand protocol stack.

9. Download the compiled Context data structures, the CALInterpreter, and the I/O routines to the target hardwareenvironment.

10. Test the application by monitoring message traffic againstapplication operation.

The Design Problem

This section steps through the design of a typical consumer product;discusses the design process emphasizing network requirements; illus-trates how the product is built; and demonstrates the benefits of inter-operation with other products. The product used for the example is aresidential thermostat. The thermostat is easy to understand and simplein operation, yet makes an interesting design example.

Product Requirements Our CEBus-compliant thermostat will per-form most of the tasks found in conventional thermostats plus someadditional functions only possible with CEBus. The thermostat can beretrofitted to an existing heating/cooling system, or it can be used overthe CEBus network to operate networked heating/cooling equipment.The basic requirements are straightforward.

235

Figure 9.6Products with existingmicroprocessors maychoose to add all ofthe necessary soft-ware in the existingprocessor memory.

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 thethermostat, or by another networked product) based on thetemperature measured at the thermostat.

It can control the system air circulation fan (if equipped). Fancontrol 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 outsidetemperature, the current setpoint, and configuration information.

The desired temperature setpoint, entered at the thermostat, willbe used to set the heating setting and cooling setting asappropriate for heating-only equipment, cooling-only equipment,or both (heat pump).

To save energy, the thermostat can use the arming state of a CEBus-com-pliant security system (if available) to set back or set forward the desiredtemperature.

Network Requirements

The operating mode, fan control, and heating and cooling setpointcan be set or read over the network by any other CEBus-compliantproduct.

The inside temperature measured by the thermostat can bebroadcast 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 andnode address.

Design RequirementsThe thermostat design requirements will be kept as simple as possible.

It will be based on a simple 8-bit microcontroller.

Product Development

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 nodeaddress, 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 toconventional equipment wiring for retrofit installation.

It can use either the power line or twisted-pair (but not both) to com-municate because either medium can supply operating power.

The Hardware Figure 9.7 is a simple block diagram of the thermostatthat meets the functional requirements. The microcontroller has suffi-cient OTP or FLASH RAM to hold the software; RAM to hold a limitedamount of variables; I/O ports to interface to the user display and con-trols; a triac or relay interface to equipment wiring; a serial or parallelport for the temperature sensor (internal or external A/D function); andparallel I/O lines for the network transceiver. The processor needs to befast enough to keep up with incoming and outgoing packets at 10 Kbpsand still have idle time available for temperature control algorithms andthe user interface. Because the temperature control software is not timecritical, this should be no problem with a microcontroller clock speedof 8 MHz or more.

The user interface consists of an LCD display, setpoint up/down but-tons, a fan switch, and a system on/off switch. The thermostat obtains itspower from the network (either 120V AC or 10—15V DC from twisted-pair) 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 theuser interface and control calculations. As a CEBus-networked product,it must contain the interface to the network variables and contain theprotocol code, including a simple CAL Interpreter.

The processor’s time is allocated to the software in the followingpriority:

1. Process incoming packets and generate necessary acknowledgments

2. Handle user inputs

3. Handle outgoing packet transmission

4. Execute background control algorithm

237

238 Chapter Nine

The network design of this product (the choice of CAL Contextdata structures) is based on the existing CEBus HVAC contexts. Figure9.9 shows a portion of the Context interconnect diagram for the con-texts that will be used for the thermostat implementation. The Con-text interconnect diagram defines how this product will work withother products on the network, what information is available from

Figure 9.7Hardware block dia-gram of the thermo-stat used for thedesign example. Thedesign can use eitherthe PL or TP as a net-work medium.

Figure 9.8Software block dia-gram of the thermo-stat.

Product Development

other products, and what information is provided by our thermostat.The Contexts to be implemented in the thermostat are shown in thecenter.

The Environmental Zone Context (40) is intended to be implement-ed in devices such as thermostats that control heating/air condition-ing equipment. This is the main Context in our design. Only a few ofthe 15 objects in the Context will be needed for network operation ofthe thermostat.

The Environmental Zone Control (43) Context is used in products inother product categories (such as a TV) that want to interoperate with athermostat. The objects in this Context bind to equivalent objects inContext 40.

239

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

240 Chapter Nine

The Environmental Zone Equipment (44) Context is implemented inheating or cooling equipment in the same product category, such as afurnace, heat pump, or base-board heater. The objects in this Contextalso bind to equivalent objects in Context 40.

The Environmental Sensor (41) Context contains the Inside Tempera-ture object. This object holds the current value of the measured temper-ature in degrees Fahrenheit. In addition to being used internally, thevalue 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 Tem-perature object. This object will receive any outside temperature broad-cast by an optionally installed outside temperature sensor. If there is nobroadcast value, the object will use a default value to indicate no validvalue has been received. The received value, besides being displayed forthe user, can be used by the thermostat application software to antici-pate heating and cooling requirements.

The Security Partition Control (62) Context is part of the SecurityContext group. This Context is intended to be in any product thatwants to control or monitor the status of the house security system. ThePartition Status object is used to monitor the arming state of the securi-ty system (broadcast from the Security Partition Context (62), PartitionState object). The received value is used to alter the settings of the ther-mostat for more efficient operation.

The binding between Contexts 43 and 40 and between Contexts 62and 63 provide interproduct interoperability. The binding between Con-texts 44 and 40 and between Contexts 41 and 42 provide intraproductinteroperability. Context 40 will contain only five of the objects availablein that Context (in addition to the Context Control object): the ZoneMode, the Zone Operating State, the Fan Control, the Heat Setting, andthe Cooling Setting objects, because this is all that the thermostat iscapable of doing. The Zone Mode object (in Context 40) is a networkinput/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 applicationsoftware as a result of input from the user interface, or from Context 43.The Zone Operating State is a network output object that contains avalue computed by the thermostat—OFF (0), HEAT ON (1), or COOL-ING ON (2)—based on the Zone Mode, the desired temperature, and theInside Temperature. This value is transmitted to the equivalent object inContext 44 to control the heating/cooling equipment accordingly. TheFan Control object is a binary switch class, network input/output objectthat can be set from the thermostat or by a message from the Fan Con-trol object in Context 43. Its value is binary: AUTO (0) or ON (1).

Product Development

The Heat Setting and Cooling Setting objects can be set over the net-work from Context 43, or they can be set locally by the thermostat. Ifthe desired temperature on the thermostat is changed by user input, newvalues 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 desiredtemperature dt, where dt is a temperature offset established by the useror fixed in the software (usually 1 to 3 degrees). If the Partition Statusobject in Context 63 receives a value that indicates that the security sys-tem is armed in the AWAY mode, meaning the house is unoccupied, thenthe thermostat will adjust its heating/cooling setting by a changing dt toa larger value (usually 3 to 5 degrees). When the object value is anythingother 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, EnvironmentalSensor, Environmental Status, and Security Partition Control. Imple-mentation requires creating a small data structure of variables to holdthe necessary IVs used in each object. This data structure is typicallyimplemented as a set of C structures; one to contain the implementedContext numbers with a pointer to each object structure, and the othersto hold the object variables.

Every CEBus node contains a Universal Context (00), Node Controlobject (class 01) that contains the node’s system, node, and groupaddresses, as well as the context_list. Our implementation will also con-tain a serial number, product class, group address, and several other vari-ables for field addressing. The product_class (23) identifies this product asa thermostat.

Typical values are shown where applicable for each implemented IV ineach implemented object. The Zone State, Fan Control, and Inside Tem-perature objects will bind to other input objects, and will therefore con-tain the reporting IVs necessary to generate report messages to other con-texts. Each of their report_condition IVs contains C delta 1 (when Cchanges by 1). The report_header IVs contain the destination ContextID/object number, followed by the setValue C method and IV, followedby the ESCAPE token. The reporting_address is shown as SA,0000, that is,the system address and the broadcast node address (0000). The systemaddress will be determined when the thermostat is installed. For installa-tions in which there is only one heating/cooling zone, using the broadcastnode address works fine. If there are multiple zones and the thermostat

241

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

242 Chapter Nine

needs to be part of the equipment in one zone only, a valid nodeaddress must be acquired.

Address Configuration The thermostat will acquire its system andnode address by using either address self-acquisition or directed acqui-sition. Self-acquisition will be accomplished using the “address config-uration” button on the thermostat. This is a combination momentary

Figure 9.10Graphical representa-tion of Context datastructure for thermo-stat product. TheContext Controlobject in each Con-text is not shown.

Product Development

push-button and LED. The button is used to perform all the tasks neces-sary to have the thermostat get a new system and node address, acquirean existing system address from another node in the house, or propagateits acquired system address to another node.

When the thermostat is first installed, it is unconfigured; the config-ured IV is FALSE and its system_address and node_address IVs contain zero.Whenever the configured IV is FALSE, the address configuration buttonLED blinks at a 1 second rate (similar to a flashing 12:00). When the con-figured IV is TRUE (and the thermostat is not executing address config-uration software) the LED is out. During address configuration, theLED is used to indicate the state of the configuration process (success,waiting, and so on). The following table itemizes the use of the but-ton/LED to perform the various address configuration tasks.

Desired Event User Action LED indication

Get new system Press and hold If successful, blinks twiceand node address button at least quickly and goes out. (first device in home). 3 seconds. Otherwise continues

to blink at 1 second rate.

Enter address Press button once. Blinks rapidly. Whenacquisition Slave mode. configured by Master,Get a system address LED goes out. If process times from another node. out unsuccessfully, LED

returns to 1 second rate.

Enter address acquisition Press button twice If config-master is acquired,Master mode. Propagate (within 1 second). LED remains on steadysystem address to If config master is in use, LED another node. remains out. Remains on steady

until config. master times out.

As an aid to directed acquisition, anytime the thermostat enters theaddress acquisition Slave mode, it broadcasts the contents of its serial_#IV using the following message syntax:

00 F4 <length string> 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 aPC), to then send a valid system and node address using the serial num-ber to condition the command.

243

244 Chapter Nine

CAL Interpreter Design The CAL Interpreter used in the thermostatis a simple parser/interpreter The Interpreter has two tasks to perform:

1. Parse incoming messages and update the data structure based onthe message.

2. Scan the data structure to determine whether a reportingcondition has been met, and generate a reporting message. Thistask is performed in the background when there are no incomingmessages to process.

Parsing incoming messages consists of performing a lookup on the tar-get Context/object to determine whether it is implemented. If it is notimplemented, an error message is returned. If it is implemented, themethod is performed on the argument IV. If the method generates areturned value (from a getValue or getArray method), then the value isreturned in a reply message. Regardless, the result of the method (erroror 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 valuesor to look for any new, network-updated values. Typically, a flag bit isused 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 devel-opment system products available. CEBench from the Intellon Corp. inFlorida, and CEBox and CELab from Domosys Lab Corp. in Quebec, arethe most complete development system products. CEBench is Motorola6811 series based and CELab is 8051 based. Both systems run onPC/Windows and provide a library of CEBus Contexts and objects formost industries. They supply a portion of the protocol and CAL Inter-preter that can be linked to and downloaded with customer-developedapplication code. While these systems are loaded with nice-to-haves,development can be done with any existing microcontroller develop-ment system. The source code for the CEBus protocol and CAL Inter-preter can be purchased, modified for the features desired, and com-bined with application code using an existing development system.Other tools, such as CEBus power line ISA cards, serial modems, networkanalyzers, transceivers, and prototype boards, are also available. After the product is prototyped, its network operation can be tested by using

Product Development

the tools in the development systems, or by using network monitoringsoftware and a PC modem.

Because the Data Link layer code is the most time critical, it is availableROMed into several small microcontrollers (such as the Motorola 6805).This might be a good alternative for a product with an existing micro-processor that is tied up with fast response-time requirements. IntellonCorp. makes an IC with the Data Link layer and power line transceiver onone chip. Domosys makes a perfect IC (CEWay) for our thermostat. It hasan 8051 application processor, a separate on-chip protocol processor, apower-line transceiver, RAM, NVRAM, OTP EPROM, LCD driver, A/Dconverter, 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 stand-alone product? Our networked thermostat has many advantages over asimilar conventional product.

It can be easily installed anywhere, communicating over anexisting medium and obtaining temperature readings from aremote temperature sensor.

It can provide the status of the heating system and the temperatureto other products.

It can use information from other products (remote temperature,outside temperature, security state, and the like), providing moreefficient and economical operation.

It can be operated by (and from) any other CEBus-compliantproduct.

It can operate any manufacturer’s CEBus-compliant heatingequipment.

This thermostat is a typical “transition” product. It contains both aconventional user interface as well as a network interface. As networkedconsumer products become more prevalent—as CEBus-compliant TVsand PCs enter the market—future versions of this thermostat can elimi-nate the user interface and conventional HVAC wiring interface, greatlylowering cost. In fact, the conventional thermostat will likely disappearaltogether. There will only be networked temperature sensors; the com-putation being absorbed by the heating equipment or a PC.

245

246 Chapter Nine

Minimum Requirements—Deciding What to ImplementAs this book has stated many times, CEBus is intended to be extendedand enhanced. As a result, the standard has many protocol and languagefeatures that are extensions of the minimum required implementation.The intent was, whenever possible, to weigh the cost of a feature (such asauthentication) against the potential uses and consequences of having thefeature required rather than optional. The test for requiring a protocol orCAL service is usually the resulting impact on a light switch (the lowestform of CEBus life). If it is required, then a light switch must have it. Forthis reason, many of the capabilities of the CEBus protocol and CAL areoptional, including certain contexts, objects, and IVs. However, a basic setof core requirements must be met in every node, including the lightswitch. The basic set of minimum requirements is given in the followinglist by protocol layer.

Data Link Layer

Any CEBus-compliant node Data Link layer must perform the followingtasks:

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, orAddr_unack_request. Rejection of Addr_ack_request, andAddr_unack_request requires that at least one address/sequencenumber association be maintained.

Respond to Ack_request with an Ack or Fail, and to anAddr_ack_request with an Addr_ack that contains a success orfailure code.

Generate a Fail or Addr_ack (failure) response if a packet wasreceived 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 receivedcorrectly requesting Ack service (Ack_request or Addr_ack_request).

Product Development

Maintain and supply the system and node address if requestedfrom a higher layer.

Recognize own system, node, and group addresses, and thebroadcast system and node address (0000).

System, node, and any used group address must be retained duringpower 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, andB1 bits cleared.

Must be capable of receiving packets with an NPDU header ofmore than 1 byte under the following conditions:

1. If AM 1, then the allowed media byte is parsed but ignored2. If BR1 or BR2 1, then the address bytes are parsed but

ignored

Generate a proper ID_Packet when first configured (addressesinstalled), upon power-up after being configured, or after thesystem or unit address changes.

Generate a proper ID_Packet if a request_ID NPDU header isreceived.

Application Layer

Following are tasks of the application layer.

Shall receive and process a nonsecure 1-byte header with thefollowing APDU types: implicit_invoke, explicit_invoke,conditional_invoke, and explicit_retry.

Shall reject duplicate messages for any of the above types bymaintaining at least one invoke ID/source address association.

Shall generate the necessary Result response with the correctinvoke ID, in response to explicit_invoke or explicit_retry, orconditional_invoke if a result condition exists.

247

248 Chapter Nine

Shall generate the necessary Reject response with the correctinvoke ID and reject_reason, in response to explicit_invoke orexplicit_retry for any of the listed Message Transfer rejectreasons.

Shall use an explicit_invoke or explicit_retry to return therequested Instance Variable value when required by certain CALmessages (getValue, getArray).

Shall include a source address in the packet when required byexplicit_invoke, explicit_retry, and conditional_invoke

CAL

General

A node shall respond to a hail from another device for its ownnode or system address (see Methods below) anytime a device isconnected and powered (regardless of any IV state, includingon_offline).

Syntax

Parser shall handle at least a single command in the message fieldof 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 ofmethods on implemented object IVs. The minimum set is:setON, setOFF, getValue, setValue, on boolean IV’sgetValue, setValue, on numeric IVsgetValue, setValue, on character IVsgetArray, setArray on data IVs with the following limits:

getArray IV to retrieve all of the IVsetArray IVDELIMITERDELIMITERdata

Inherit, disinherit on resource IVs, if implemented.Exit method followed by an argumentThe IF syntax with the following format:

IF IV.EQ.Value BEGIN simple method END

Product Development

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 everyContext and the object_list IV shall be supported.

Contexts

The Universal Context shall be implemented and must contain theNode Control object.

Context number usage shall be supported (A0 to DF) followed bythe Context class if multiple contexts of the same class are used.

ErrorsAn error shall always be returned in response to an explicit_invoke ifthe requested message cannot be executed properly.

Certification (ANSI/EIA-633)Concurrent with the development of EIA-600, the EIA and the CEBusCommittee set about the task of developing a rigorous test procedure forproducts implementing CEBus. This “certification” document wasreleased in the late 1990s as EIA-633. EIA-633 is structured almost identi-cally to EIA-600 on a chapter-by-chapter basis to provide a complete testprocedure 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 asinterference levels and signal strengths.

Complete test procedures are given for the nonphysical layers, includ-ing the CAL Interpreter, to make sure a given implementation meets allthe required functions of each layer including timing requirements andcurrent error responses. Test parameters are also listed for optional ser-vices such as Network layer segmented service.

249

250 Chapter Nine

The intent of EIA-600 is to enable a product developer to perform allthe necessary tests on a product to determine whether it will work reli-ably with other manufacturers’ CEBus-compliant products on the samenetwork without having to resort to a trial-and-error process in the mar-ket. If a product passes the tests described in EIA-633, it will work withother products that also pass the tests.

PlugLab

In 1996, the CEBus Industry Council began working with Purdue Uni-versity to form an independent testing facility for CEBus- and HomeP-nP-compliant products. The facility was designed to provide completefacilities to test CEBus-compliant products to EIA-633, and HomePnP-compliant products to the HomePnP Specification. The facility is nowan official department of IUPUI (Indiana University/Purdue Universityin Indianapolis) and is officially called PlugLab. Its role is to provide test-ing and/or certification services for products that use the CEBus protocoland/or that implement the HomePnP specification. HomePnP can betested independently from the transport protocol.

The facility also provides testing and certification services for otherhome-related network technologies, including HomePNA and HomeRF.

APPENDIX A

251

OBJECT DEFINITIONS

This appendix contains a list of the CAL object tables and reference dataregarding their proper use. The tables give a definition of the CEBusCAL Objects. All usable objects are given (excluding the Node Controland Context Control objects). The tables describe the object class, thetypical object binding, and the IVs used in the object.

Common Object IV LabelsMany of the object definitions use a set of reserved letters, indicated byuppercase, to label commonly used IVs that occur in most objects. Theremaining IVs in each object, unique only within the object, are labeledusing lowercase letters. The ASCII code of an IV is the data transmittedin a CAL Method to indicate a particular IV. The reserved, uppercase let-ters of some IVs are listed below.

Label IV Name IV Description

R reporting_condition Data value (Boolean expression) used to indicate under whatcondition 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 ofthe other IVs in the object. (See Appendix B)

C current_value The primary variable of the object. May be named specificto 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 cur-rent_value.


252 Appendix A

Label IV Name IV Description

F function_of_position A data array that stores a text string description of each ofthe positions of the current_position IV of a switch-typeobject. Each element of the array is eight characters. ThegetArray and setArray methods are used to read or writeone or more elements of the IV. To read a switch position usethe getArray method with <offset> set to the desired position and <count.> set to 1. The text strings used are given in the Context document in which the switchobject is used.

Manufacturer IVsEight 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 labelsmay be used in devices for “private” applications in which standardizedinteroperability is not necessary.

Object TablesThe following object tables are given in object class number order.

Object Categories

The objects can be generally divided into two categories: general pur-pose and special purpose. The general purpose objects can be used tomodel many different control and sensing functions in a broad categoryof contexts. Ninety-five percent of the objects used in all contexts con-sist 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

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 andmodel a unique function found only in a few applications. The objectswere developed to make implementation of the modeled function easierby 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 byusing combinations of the general purpose objects, but would requirekeeping track of many IVs across object boundaries.

Table Notes

The possible binding shown in each table is the most likely, cross-contextbinding for the object. Other bindings may be possible if the range andvalues 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)

253

254 Appendix A

Appendix A 255

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

Appendix A 257

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

Appendix A 261

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.

Appendix A 265

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.

Appendix A 267

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.

Appendix A 269

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.

Appendix A 271

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

Appendix A 273

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

275

SAMPLE CONTEXTS

This appendix contains sample Context tables for two common Con-texts. Not all of the objects in the Contexts may be shown. Consult theContext tables directly for the full Context document. Because mostContexts were still under review when this book was written, theseContexts may have changed. Check with the CIC.

Context 10 (Audio)The Audio Context is part of the A/V industry group and illustrateshow typical audio amplifier functions are implemented. Only the firstten 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 oneof the few Contexts that is intended to bind to itself (that is, anotherLight Context) since it contains objects for either a device that sendsmessages to a light, or for a device to receive messages at a light.

The Light Context contains the necessary objects for control of a sin-gle light/light switch device. It can be used in a light switch device tocontrol a remote light, or in the light, or both. This Context binds withanother Context 21.

Appendix B 281

Predefined Values for the feature IV:

0– No feature selected/stop feature1– Ramp brightness to maximum2– Ramp brightness to minimum3– Store ‘C’ to ‘s’ and turn off4– Store ‘C’ to ‘s’ and ramp off5– Turn on to ‘s’ brightness level6– Ramp on to ‘s’ brightness level7– Turn on to local brightness level8– Ramp on to local brightness level9– Set current brightness to minimum10– Save ‘C’ to ‘s’ and flash brightness level on/off11–99 Reserved for future use.

282 Appendix B

Appendix B 283


APPENDIX C

285

RESPONSE ERROR CODES

The following table gives the error codes returned in a response ASDUwhen 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 com-posed 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 parsingerror.

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

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

10 Inherit Disabled Error returned after a request to inherit if devicedisallowed to inherit resources.

11 Value Out of Range Attempted to set an IV to a value outside of itsallowable range.

12 Bad Argument Type Attempted to perform an operation on an IV ofimproper data type.

13 Power Off Attempted to execute a method while the power IVin the Node Control object was off.

14 Invalid Argument Attempted to use an argument not accepted by themethod.

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 Error code returned when resource allocation fails Resource and no other error code applies (for example, cannot

join any other groups).

18 Precondition Attempted to perform an operation when some Incomplete 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 com-plete the operation.

20 No Support The requested operation is not supported by theapplication. 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 support-ed by the device.

22 Application Error Allows the application to return an Error message.Error/Response codes 0−99 are reserved for assign-ment by the EIA. Values greater than 99 can be usedby manufacturers for other (product-specific) indica-tions.

APPENDIX D

287

CEBUS RESOURCES

CEBus Industry CouncilIndustry trade organization for companies with a business interest inCEBus. Provides technical and marketing services such as certification,Context generation, and trade show production (CEBus Pavilion). Pro-vides Context documents and related CEBus documentationPhone: 317-545-6239Internet: www.cebus.org

Global EngineeringGlobal Engineering sells the EIA-600 document(s). They are the document production facility for the EIA.Contact: standard sales800-854-7179www.global.ins.com



INDEX



291

AAcknowledged service, 148–154Addresses/addressing, 157–160

acquiring/keeping, 160allocation of, 205–207node address, 158–159and product design, 230–231,

242–243self-acquisition, address, 208–212system address, 157–158

Analog Control object, 257Analog Sensor object, 258ANSI/EIA-600, 2, 12–18

brouter communication protocol,15

CAL, 15, 18description, 13–14introduction, 13node communications protocol,

14–15, 17–18physical layers, 14, 16–17router communication protocol, 15supplemental data, 15

ANSI/EIA-633, 249–250ANSI/EIA-721, 7, 215–218ANSI/TIA-570, 43ANSI/TIA-570A, 3, 71APDU (see Application Protocol Data

Unit)Application layer, 48, 95

CEBus protocol, 98–118APDU Header, 101–105and CEBus product application,

98choice of service, 112–114conditional_invoke service, 109explicit_invoke service, 105–108explicit_retry service, 109–111Extended (security) Services,

114–118invoke_ID, 111–112Reject APDUs, 112

Application layer, CEBus protocol (Cont.) :

subparts, layer, 100–101synchronous service, 110, 111

minimum requirements for,247–248

Application Protocol Data Unit(APDU), 96, 97

Header, APDU, 101–105Reject APDUs, 112

Application-level interoperability,31–32

Audio Context, 275–279Balance Control object, 278Bass Control object, 278Context Control object, 275Input Mode Switch object, 277Mute Setting object, 279Processing Switch object, 277Source Switch object, 276Treble Control object, 279Volume Control object, 276

Authentication, 21, 48, 115–117

BBalance Control object (Audio

Context), 278Basic Service APDU Header, 101–103Bass Control object (Audio Context),

278Binary Sensor object, 256Binary Switch object, 256Boolean variables, 173Brouters, 58, 59, 121, 122

CCable TV, 3Cabling:

CX networks, 77–80

292 Index

Cabling (Cont.) :PL networks, 62–64TP networks, 71–74

CAL (see CEBus Common ApplicationLanguage)

CAL Interpreter, 39, 213–215in Application layer, 100–101,

112–114and peer-to-peer communications,

95–96CEBC (see Consumer Electronic Bus

Committee)CEBench, 244CEBox, 244CEBus (see Consumer Electronic Bus)CEBus Common Application

Language (CAL), 51–52,164–218

assumptions of, 165–166and CEBus product model, 37–39Contexts in, 166–192

Context Control object in, 190current (list), 167–169examples of, 185–191function of, 166and objects, 167, 169–185and product capability, 191specifications for, 191–192Universal Context, 186–190

in EIA-600, 15, 18Generic CAL, 215–218goals of, 164–165implementation example, 204, 205Interpreter, CAL. (see CAL Inter-

preter)messages in, 192–204

command messages, 192–193generation of, 199–204and methods, 195–199non-CAL messages, transporting,

214–215response messages, 193–195


objects in, 167, 169–185binding, object, 180–185categories of, 179–181definition of, 169–178

CEBus Common Application Language, objects in (Cont.) :

function of, 167, 169implementation of, 178–179predefined, 170

resource allocation in, 204–212address allocation, 205–207node addressing, 207–208self-acquisition, address, 208–212

CEBus Industry Council (CIC), 7, 33,191, 287

CEBus protocol, 92–162addresses in, 157–160

acquiring/keeping addresses, 160node address, 158–159system address, 157–158

Application layer of, 98–118APDU Header, 101–105CEBus product application vs., 98choosing service in, 112–114conditional_invoke service, 109explicit_invoke service, 105–108explicit_retry service, 109–111Extended (security) Services,

114–118invoke_ID, 111–112Reject APDUs, 112subparts of, 100–101synchronous service, 110, 111

Data Link layer of, 135–154and CSMA/CDCR, 140–145end-of-field (EOF) symbol, 139end-of-packet (EOP) symbol, 139functions of, 135–136leading zero suppression,

139–140packet delivery services in,

145–154packet format in, 137–139structure of, 136–137

and Homenet, 92implementation issues with,

160–162and layer system management,

161–162Network layer of, 118–135

Extended Services, 122–130ID Packets, 133–135

Index

CEBus protocol, Network layer of(Cont.) :

IR/RF Packets, 130–134NPDU Header, 119–122

and OSI model, 92–95and peer-to-peer node communi-

cations, 95–97Physical layer of, 154–157and transmission failures, 97–98

CELab, 244Certification (for CEBus-compliant

products), 249–250Channels, 44–46

control, 44data, 44

Character string variables, 174Chirp, 65, 69, 70CIC (see CEBus Industry Council)Clock object, 273Cluster control model, 41Command messages, 192–193Communication channels, 44–46Communications-level interoperability,

30–31Conditional_invoke service, 109Connectionless service protocols,

40, 41Consumer Electronic Bus (CEBus):

design constraints with, 19–20development goals of, 6features of, 2–3future potential of, 28–29history of, 2, 6–7network topology of, 54–62

global network, 61medium networks, 60Node 0, 55, 56reference architecture, 54–55router/brouter requirements,

56–60system network, 60, 61WAN, connection to, 61–62

requirements established for, 5–6as residential network, 4resources on, 287security issues with, 20–21typical applications for, 26–27(See also specific headings)

Consumer Electronic Bus Committee(CEBC), 6–7

Context Control object, 190, 191Audio Context, 275Light Context, 280

Contexts, 51–52, 166–192Context Control object in, 190current (list), 167–169examples of, 185–191, 275–283function of, 166and objects, 167, 169–185and product capability, 191specifications for, 191–192Universal Context, 186–190

Control channels, 44Control function, 167Control messages, 25–26Control models, 41–42Counter/Timer object, 272CSMA/CDCR protocol, 97, 140–145

and channel access optimization,140–141

contention, avoidance of, 141–144contention, resolution of, 144–145goal of, 140retransmission, allowing, 145

Current_value IV, 180CX (coaxial) network, 76–84

cable specification for, 77–78connectors for, 79–80control channel for, 83, 84data channel for, 81–83Node 0 distribution device for,

80–81physical layer implementation for,

83, 84topology of, 78–79

DData Channel Bridges, 59–60Data Channel Receiver, 254Data Channel Transmitter, 254Data channels, 44Data Link layer, 48, 94

CEBus protocol, 135–154and CSMA/CDCR, 140–145

293

294 Index

Data Link layer, CEBus protocol(Cont.) :

end-of-field (EOF) symbol, 139end-of-packet (EOP) symbol, 139functions, 135–136leading zero suppression,

139–140packet delivery services,

145–154packet format, 137–139structure, layer, 136–137


Data Link Protocol Data Unit(DLPDU), 97

Data Memory object, 268Data variables, 174–175Deregulation of communication

industry, 3Dialer object, 265Display object, 263Distributed control model, 41DLPDU (Data Link Protocol Data

Unit), 97Domosys Lab Corp., 244, 245Duplicate IR/RF packet problem,

121–122, 130–134

EEIA (see Electronics Industries

Alliance)Electric meter, 27Electronics Industries Alliance (EIA),

2, 6, 12Encryption, 21, 117End-of-field (EOF) symbol, 139End-of-packet (EOP) symbol, 139Error codes (list), 285–286Explicit_invoke service, 105–108Explicit_retry service, 109–111Extended Service APDU Header,

103–105Extended Services:

Application layer, 114–118authentication, 115–117encryption, 117

Extended Services (Cont.) :Network layer, 122–130

bytes, 123–125and flow control, 127–130segmented service example,

125–127specifying Extended Service, 123

FFault detector, 28–29FCS (see Frame Check Sequence)Feature Select object (Light Context),

282Frame Check Sequence (FCS), 48,

98–99Frames, 94

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

HHardware, product design and, 237Homenet, 7, 92HomePnP, 220–225

and CEBus-compliant products,249–250

and Generic CAL, 221–222goals of, 222–223problems addressed by, 225self-configuration of, 225state vector in, 224

House mode, 224HVAC systems, 41–42

IIBM, 5ID Packets, 133–135

Index

INFERIOR state, 49–50, 66–67, 74, 75,86–87, 144, 155, 156

Input Mode Switch object (AudioContext), 277

Instance variables (IVs), 52, 171–177active IVs, 172boolean, 173character string, 174current_value IV, 180data variables, 174–175labels identifying, 172–173, 251–252manufacturer-defined, 176, 252numeric, 173–174and object instantiation, 176–177read/write vs. read-only, 173reporting IVs, 172, 176required vs. optional, 175support IVs, 171, 172volatility of, 175

Intellon Corp., 244, 245International Standards Organization

(ISO), 92Interoperability, 30–33, 220

application-level, 31–32communications-level, 30–31and plug-n-play, 29–30and product design, 231–232scenario-level, 33

Invoke_ID, 111–112ISO (International Standards

Organization), 92IVs (see Instance variables)

KKeypad object, 266Keys, 21

LLayer system management, 161–162Leading zero suppression, 139–140Level Display object (Light Context),

283Light Context, 280–283

Context Control object, 280

Light Context (Cont.) :Feature Select object, 282Level Display object, 283Light Level Control object, 281Light Level Setting object, 282

Light Level Control object (LightContext), 281

Light Level Setting object (LightContext), 282

List Memory object, 267Locking, 225LonTalk, 220LORAN, 65

MMAC sublayer (see Media Access

Control sublayer)Macros, 199Malfunction detector, 28–29Matrix Switch object, 261MDS (Medium Dependent Sublayer),

155Media, wired vs. nonwired, 54Media Access Control (MAC) sublayer,

136–137Medium Dependent Sublayer (MDS),

155Medium networks, 60Medium Transport object, 264Message Transfer Element (MT

Element), 100, 101, 104–114conditional_invoke service, 109explicit_invoke service, 105–108explicit_retry service, 109–111invoke_ID, 111–112and Network layer, 118

Messages, 47–50authentication/encryption of, 21,

48, 115–117in CAL, 192–204

command messages, 192–193generation, message, 199–204and methods, 195–199non-CAL messages, transporting,

214–215response messages, 193–195

295

296 Index

Messages (Cont.) :control, 25–26status, 26

Meter object, 262Methods, 195–199

macro identifiers in, 199required vs. optional, 198–199table, method, 195–198

Microsoft, 5MoneMinder, 7Motor object, 269MT Element (see Message Transfer

Element)Multiposition Sensor object, 260Multiposition Switch object, 259Mute Setting object (Audio Context),

279

NNetwork configuration devices,

29Network control model, 41–42Network Interface Units (NIUs), 44,

61, 62Network layer, 48, 94

CEBus protocol, 118–135Extended Services, 122–130ID Packets, 133–135IR/RF Packets, 130–134NPDU Header, 119–122

minimum requirements for, 247

Network layer management, 95Network Protocol Data Unit (NPDU),

96, 97, 119–122brouter addresses, 121and duplicate IR/RF packet

problem, 121–122routing, 121Service byte, NL, 119–121

Networked products, benefits of,24–25

NIUs (see Network Interface Units)Node 0, 55, 56, 80–81Node address, 158–159Node addressing, 207–208

Node Control object, 191Nodes, 37, 38, 42, 49Nonwired media, 54NPDU (see Network Protocol Data

Unit)Numeric variables, 173–174

OObjects, 51–52, 167, 169–185

binding, object, 180–185categories of, 179–181definition of, 169–178function of, 167, 169implementation of, 178–179predefined, 170tables, object, 252–273

One-way authentication, 116–117OSI model, 92–95

PPackets, 47–50, 94

in DLL, 145–154acknowledged service, 148–154addressed unacknowledged

sequence, 147–148addressed unacknowledged

service, 146–147unacknowledged service, 146

format for, 98–99, 137–139PL, 67–68

Peer-to-peer communications, 40,95–97

Personal computer, 27Physical layer, 42, 93, 94

CEBus protocol, 154–157CX networks, 83, 84in EIA-600, 14, 16–17PL networks, 68–70RF communication, 87–89

PL (power-line) network, 62–71CEBus signaling on, 64–67packet encoding on, 67–68performance considerations with,

70–71

Index

PL (power-line) network (Cont.) :physical layer implementation for,

68–70topology of, 62–64

Plug-n-play, 29–30. (See also HomePnP)Predefined objects (CAL), 170Presentation layer, 94Processing Switch object (Audio

Context), 277Products, CEBus-compliant, 228–250

benefits of, 24–25, 245building the product, 244–245certification for, 249–250design of, 228–232, 234–244

and address configuration,242–243

and addressing, 230–231CAL interpreter, 244and design requirements,

236–237hardware, 237, 238and interoperability, 231–232and network requirements, 236and product requirements,

235–236and security, 229–230software, 237–242steps in, 234–235

and HomePnP specification,249–250


Application layer, 247–248CAL, 248–249Data Link layer, 246–247Network layer, 247

model for, 36–42partitioning of processing tasks in,

232–234Protocol (see CEBus protocol)

RReject APDUs, 112Report_address IV, 203–204Report_condition IV, 201–203Report_header IV, 203

Reporting IVs, 172, 176Residential network technology,

need for, 3–4Resource allocation (in CAL),

204–212address allocation, 205–207node addressing, 207–208self-acquisition, address, 208–212

Resource providers, 26Response ASDUs, 193–195Response error codes (list), 285–286RF (radio-frequency) communication,

84–89encoding for, 85–87physical layer implementation for,

87–89spectrum signaling for, 84–85

Routers, 56–59RS-232, 220

SScenario-level interoperability, 33Security issues, 20–21

Application layer, 114–118and HomePnP, 225Network layer, 122–130and product design, 229–230

SES (see Symbol Encoding Sublayer)Session layer, 94Software, product design and,

237–242Source Switch object (Audio Context),

276State vectors, 224Status messages, 26Subsystem definitions, 221SUPERIOR state, 49–50, 66–67, 74,

85–87, 144, 155, 156Support IVs, 171, 172Symbol encoding, 48–50Symbol Encoding Sublayer (SES),

155–157Synthesizer/Tuner object, 270System address, 157–158System guidelines, 221System network, 60, 61

297

298 Index

TTelecommunication Industry Associ-

ation (TIA), 71Telephone companies, 3Television, 3, 166Temperature sensor, 27TIA (Telecommunication Industry

Association), 71Tight coupling, 223Time module, plug-in-the-wall,

26–27Tone Generator object, 271TP (telephone) network,

71–76cable/wire specifications,

71–74control channel for,

74–75physical layer implementation for,

75–76Transport layer, 94Treble Control object (Audio

Context), 279Two-way authentication, 116

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

VVideo interface device, 27Volume Control object (Audio

Context), 276

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

XX-10 message protocol, 220

About the AuthorGrayson Evans has been actively involved in home automation and communica-tion network development and training for the past two decades. He is thefounder of The Training Department, a company specializing in CEBus and res-idential technology training. For the past 12 years, he has also been an engineer-ing 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 foundingboard member of the CEBus Industry Council and provides engineering con-sulting to the Home Plug & Play Specification of the CIC. He holds a Master’sDegree in Computer Science, and a Bachelor’s Degree in Architecture from theGeorgia Institute of Technology.

299

Documents

CEBus Demystified: The ANSI EIA 600 User's Guide