`
`LEBUS
`DEMYSTIFIED.
`
`UUae
`ETeC
`
`SOE
`
`VAD SLL Ex, 1018, Page 1
`
`Petitioner’s Ex. 1018, Page 1
`
`

`

`CEBus Demystified
`CEBus Demystified
`
`Petitioner's Ex. 1018, Page 2
`
`Petitioner’s Ex. 1018, Page 2
`
`

`

`This page intentionally left blank.
`
`Petitioner’s Ex. 1018, Page 3
`
`

`

`CEBus
`Demystified
`The ANSI/EIA 600
`User’s Guide
`Grayson Evans
`
`McGraw-Hill
`New York • Chicago • San Francisco • Lisbon • London
`Madrid • Mexico City • Milan • New Delhi • San Juan • Seoul
`Singapore • Sydney • Toronto
`
`Petitioner’s Ex. 1018, Page 4
`
`

`

`McGraw-Hill
`
` abc
`
`Copyright © 2001 by The McGraw-Hill Companies, Inc. All rights reserved. Manufactured in the
`United States of America. Except as permitted under the United States Copyright Act of 1976, no part
`of this publication may be reproduced or distributed in any form or by any means, or stored in a data-
`base or retrieval system, without the prior written permission of the publisher.
`
`0-07-141465-7
`
`The material in this eBook also appears in the print version of this title: 0-07-137006-4.
`
`All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after
`every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit
`of the trademark owner, with no intention of infringement of the trademark. Where such designations
`appear in this book, they have been printed with initial caps.
`
`McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales pro-
`motions, or for use in corporate training programs. For more information, please contact George
`Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212) 904-4069.
`
`TERMS OF USE
`This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors
`reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted
`under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not
`decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon,
`transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without
`McGraw-Hill’s prior consent. You may use the work for your own noncommercial and personal use;
`any other use of the work is strictly prohibited. Your right to use the work may be terminated if you
`fail to comply with these terms.
`
`THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUAR-
`ANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF
`OR 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 BUT
`NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
`PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the func-
`tions contained in the work will meet your requirements or that its operation will be uninterrupted or
`error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any 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 the
`work, 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, tort
`or otherwise.
`
`DOI: 10.1036/0071414657
`
`Petitioner’s Ex. 1018, Page 5
`
`

`

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

`

`Notable Conventions
`CEBus ⫽ CEBus Standard
`
`According to guidelines published by the EIA, the trademark “CEBus” is
`an adjective, not a noun. “CEBus” should always be used with the word
`“standard,” “compliant,” or other appropriate word since CEBus refers
`only to the ANSI/EIA-600 standard. A product that complies with
`ANSI/EIA-600 should be referred to as a “CEBus standard compliant”
`product, or “CEBus compliant.” However, to make this book easier to
`read (and to write), the word “standard” is often implied. Wherever the
`word “CEBus” is used, assume this means “CEBus Standard.”
`In this book, CEBus, EIA-600, and ANSI/EIA-600 are used to refer to
`the same official standard: ANSI/EIA-600
`
`Conflicts with the CEBus Standard
`
`If there are any differences between the information in this book about
`the CEBus Standard and the information contained in ANSI/EIA-600, the
`information in ANSI/EIA-600 should prevail.
`
`Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.
`
`Petitioner’s Ex. 1018, Page 7
`
`

`

`This page intentionally left blank.
`
`Petitioner’s Ex. 1018, Page 8
`
`

`

`For more information about this title click here.
`
`CONTENTS
`
`Chapter 1
`
`Introduction
`
`What Is CEBus?
`Why Residential Networks?
`Why Make a Standard?
`CEBus Development Goals
`Development History
`This Book’s Goals
`How This Book is Organized
`
`Chapter 2
`
`CEBus Document Overview
`
`EIA-600
`EIA-600 Attributes
`The Standard Parts
`An Introduction to EIA-600 Parts
`The Physical Layers
`The Protocol
`The Language
`The Design Constraints
`Security Issues
`
`Chapter 3
`
`The CEBus Benefit
`
`The Benefits of Networked Products
`What CEBus Products Say
`Control Messages
`Status Messages
`Typical CEBus Applications
`The Future Potential
`The Plug-n-Play Concept
`Interoperability Defined
`Communications Level Interoperability
`Application Level Interoperability
`Scenario Interoperability
`
`1
`
`2
`3
`5
`6
`6
`8
`8
`
`11
`
`12
`12
`13
`16
`16
`17
`18
`19
`20
`
`23
`
`24
`25
`25
`26
`26
`28
`29
`30
`30
`31
`33
`
`Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.
`
`Petitioner’s Ex. 1018, Page 9
`
`

`

`viii
`
`Contents
`
`Chapter 4
`
`CEBus Basics
`
`How CEBus Works—An Overview
`The CEBus Product Model
`Nodes
`Network Communications Models
`Network Control Model
`CEBus Reference Architecture and Media
`Channels
`Packets and Messages
`Symbol Encoding
`Network Attributes
`CAL:What CEBus Products Say to Each Other
`CAL View of Products
`
`Chapter 5
`
`The Media and Physical Layers
`
`The CEBus Network Topology
`Architecture Assumptions
`Node O
`Router and Brouter Requirements
`Medium, System, and Global Networks
`Connection to the Outside World
`The PL Network
`Power-Line Topology
`CEBus Signaling on the PL
`Packet Encoding
`Physical Layer Implementation
`PL Performance
`The TP Network
`TP Cable and Wire Use
`TP Control Channel
`TP Physical Layer
`The CX Network
`The Cable
`CX Network Topology
`Cable Connectors and Outlets
`Node O Distribution Device
`Coax Control and Data Channels
`CX Physical Layer
`CEBus RF
`CEBus RF Signaling
`
`35
`
`36
`36
`37
`40
`41
`42
`44
`47
`48
`50
`51
`51
`
`53
`
`54
`54
`55
`56
`60
`61
`62
`62
`64
`67
`68
`70
`71
`71
`74
`75
`76
`77
`78
`79
`80
`81
`83
`84
`84
`
`Petitioner’s Ex. 1018, Page 10
`
`

`

`Contents
`
`ix
`
`RF Control Channel Encoding
`RF Physical Layer
`
`Chapter 6
`
`Protocol
`
`A Little Protocol Background
`CEBus Protocol Overview
`The ISO vs. CEBus Model
`The Peer-to-Peer Layer Model
`Transmission Failures
`Application Layer vs. the Application
`Packet Format
`Layer Responsibilities
`Application Layer
`The APDU Header
`Basic Service APDU
`Extended Service APDU
`Basic Service Details
`Explicit_Invoke Service
`Synchronous Service and the Invoke_IDs
`Reject APDUs
`When to Use What Service
`Application Layer Extended Services
`Authentication
`Authentication Algorithms
`Encryption
`Using Secure Services
`Network Layer
`The NPDU Header
`Network Layer Extended Services
`More on IR/RF Packets and Duplicate Rejection
`IR/RF Packet Examples
`ID Packets
`Data Link Layer
`DLL Structure
`Packet Format
`EOFs, EOPs, and Leading Zero Suppression
`Channel Access Protocol
`DLL Packet Delivery Services
`Unacknowledged Service
`Addressed Unacknowledged Service
`
`85
`87
`
`91
`
`92
`92
`95
`95
`97
`98
`98
`99
`99
`101
`101
`103
`105
`105
`110
`112
`112
`114
`115
`116
`117
`117
`118
`119
`122
`130
`131
`133
`135
`136
`137
`139
`140
`145
`146
`146
`
`Petitioner’s Ex. 1018, Page 11
`
`

`

`x
`
`Contents
`
`Addressed Unacknowledged Sequence/Address Association
`Acknowledged Service
`The Physical Layer
`The PL and RF Medium SES
`CEBus Addresses
`The System Address
`The Node Address
`Acquiring and Keeping Addresses
`Implementation Issues
`Layer System Management
`
`Chapter 7
`
`CAL
`
`CAL Goals
`How CAL Models the Consumer Product World
`The Context Data Structure
`Contexts
`Objects
`Object Definitions
`Context Data Structure
`Object Network Types
`Object Binding: How Contexts Work Together
`Context Examples
`The Universal Context
`Context Control Object
`Determining Product Capability
`Where Do Contexts Come From?
`Messages: Object Communications
`Command ASDUs
`Response ASDUs
`Methods
`Message Generation
`Implementation Example
`Resource Allocation
`Address Resources and Address Allocation
`Node Addressing
`Address Self-Acquisition
`The CAL Interpreter
`Transporting Non-CAL Messages
`Generic CAL (ANSI/EIA.721)
`Differences between Generic and CEBUS CAL
`
`147
`148
`154
`156
`157
`157
`158
`160
`160
`161
`
`163
`
`164
`165
`166
`166
`167
`171
`178
`179
`180
`185
`186
`190
`191
`191
`192
`192
`193
`195
`199
`204
`204
`205
`207
`208
`213
`214
`215
`215
`
`Petitioner’s Ex. 1018, Page 12
`
`

`

`Contents
`
`xi
`
`Chapter 8
`
`Interoperability and HomePnP
`
`HomePnP Overview
`Some New Ideas
`Interoperability and HomePnp
`State Vectors
`Configuration
`Additional Problems Addressed by HomePnP
`
`Chapter 9
`
`Product Development
`
`Design Considerations for Networked Products
`Security
`Addressing
`Interoperability
`Partitioning of Processing Tasks
`Creating CEBus Applications: An Overview
`The Design Problem
`Getting It Built
`Product Benefits
`Minimum Requirements—Deciding What to Implement
`Data Link Layer
`Network Layer
`Application Layer
`CAL
`Certification (ANSI/EIA-633)
`Plug Lab
`
`Appendix A Object Definitions
`
`Common Object IV Labels
`Manufacturer IVs
`Object Tables
`Object Categories
`Table Notes
`03 Data Channel Receiver
`04 Data Channel Transmitter
`05 Binary Switch
`06 Binary Sensor
`07 Analog Control
`08 Analog Sensor
`09 Multiposition Switch
`
`220
`
`220
`222
`223
`224
`225
`225
`
`227
`
`228
`229
`230
`231
`232
`234
`235
`244
`245
`246
`246
`247
`247
`248
`249
`250
`
`251
`
`251
`252
`252
`252
`253
`254
`255
`256
`256
`257
`258
`259
`
`Petitioner’s Ex. 1018, Page 13
`
`

`

`xii
`
`Contents
`
`0A Multiposition Sensor
`0B Matrix Switch
`0F Meter
`10 Display
`11 Medium Transport
`13 Dialer
`14 Keypad
`15 List Memory
`16 Data Memory
`17 Motor
`19 Synthesizer/Tuner
`1A Tone Generator
`1C Counter/Timer
`1D Clock
`
`Appendix B
`
`Sample Contexts
`
`Context 10 (Audio)
`Context 21 (Light)
`
`Appendix C
`
`Response Error Codes
`
`Appendix D CEBus Resources
`
`Index
`
`260
`261
`262
`263
`264
`265
`266
`267
`268
`269
`270
`271
`272
`273
`
`275
`
`275
`280
`
`285
`
`287
`
`289
`
`Petitioner’s Ex. 1018, Page 14
`
`

`

`CEBus Demystified
`CEBus Demystified
`
`Petitioner's Ex. 1018, Page 15
`
`Petitioner’s Ex. 1018, Page 15
`
`

`

`This page intentionally left blank.
`
`Petitioner’s Ex. 1018, Page 16
`
`

`

`1CHAPTER 1
`
`Introduction
`
`Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.
`
`Petitioner’s Ex. 1018, Page 17
`
`

`

`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 Electronics
`Group to help formulate some form of common communication stan-
`dard for consumer devices used in homes. This standardization effort
`was a result of an earlier attempt to develop a common infrared remote
`control standard.
`If these 12 men had any idea that they were about to begin a task that
`would occupy a considerable portion of their lives—and the lives of
`dozens of others—for the next 10 years, it is unlikely that they would
`have continued the task. But, of course, they could not possibly have
`known what they were about to undertake.
`What these people started is known as the Consumer Electronic Bus
`(CEBus) home automation communication standard—a standard that
`defines a communications protocol, language, and media interface speci-
`fication that enables any device in the home to communicate with any
`other device.
`The CEBus effort, which culminated in 1992, was an impressive
`accomplishment. No other standard-setting activity that the EIA has
`ever undertaken approaches CEBus in scale and complexity. More than
`400 people and companies were involved in the successful development
`of CEBus. You are about to reap the benefits of their effort!
`
`What Is CEBus?
`
`CEBus (pronounced “see-bus”) is the common name for ANSI/EIA-600,
`a communications standard for residential consumer products. The
`standard specifies how products send and receive information,
`the media available to use the products, and what products say to each
`other.
`CEBus solves the traditional problems of integrating products and
`systems made by different manufacturers by establishing a standard,
`reliable interface to each CEBus-compliant product in the home. The
`standard provides
`
`A standardized physical interface between devices in the home so
`that information can be easily and reliably exchanged
`A standardized way for devices to interoperate and “talk” to each
`other using a common language
`
`Petitioner’s Ex. 1018, Page 18
`
`

`

`Introduction
`
`3
`
`CEBus enables stand-alone products to become networked products,
`sharing information and product “resources.” Its standardized common
`language ensures built-in interoperability and a rich set of capabilities.
`CEBus also establishes a unified, high-quality cabling standard to han-
`dle all of the data communication needs of the home (audio, video,
`CEBus product communications, computer data, etc.) for the foreseeable
`future. The cabling standard has become the basis for all current resi-
`dential infrastructure wiring products and was the basis of the revised
`ANSI/TIA/EIA-570A residential wiring standard.
`
`Why Residential Networks?
`
`During the 1990s, there was a growing need to solve a related set of com-
`munication problems in the home. These problems are the result of new
`technology products in the home (such as home computers, home
`automation systems, home theater, energy management systems, and
`telecommunication products) and the rise of wideband service
`providers. Deregulation of the communication industry in the United
`States has created new market opportunities for service providers to offer
`access to a host of wideband information “services.” Cable TV companies
`can now provide telephone and other high speed two-way communica-
`tion services. Telephone companies can provide cable TV services such as
`pay-per-view movies and information services, as well as voice and data
`communications. Utility companies can provide appliance monitoring
`and energy management services, and can offer variable electric rates
`based on their access to and ability to control in-home appliances.
`These new technologies depend on reliable communications in the
`home. Present residential wiring will not be capable of providing these
`services due to the poor quality of most existing in-home telephone and
`coaxial cable. A new residential network technology is needed. The net-
`work must provide three things:
`
`A universal, low-cost method for devices in the home to communicate
`regardless of manufacturer. There must be a way to distribute control
`and data about the operation of appliances and systems throughout
`the home. This information allows products to interoperate—
`sharing information such as time and temperature, the current
`electric rate, house occupancy, and so on. Without this capability,
`there can never be a reasonable market for home automation.
`
`Petitioner’s Ex. 1018, Page 19
`
`

`

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

`

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

`

`6
`
`Chapter One
`
`telephone wiring. It must handle the bandwidth requirements for
`distribution of outside services to any device in the home.
`3. To minimize the redundancy of control and operation methods among
`products in the home. In theory, CEBus can actually simplify the
`operation of appliances and products in the home by enabling a
`common interface to develop. For example, CEBus has the
`capability to enable a television to present menus to allow setting
`of thermostats, microwave ovens, VCRs, security systems, and the
`like, with a common onscreen interface.
`To meet the requirements for CEBus, the technical goals for the
`technology were clear: it must be retrofittable; it must support
`distributed intelligence; it must not be product specific; it must
`have an open architecture; and it must be expandable. The
`goals were met by IS-60, and products demonstrating the
`capability were built.
`
`CEBus Development Goals
`
`A stated motivation for developing CEBus is to encourage new companies
`to enter, or reenter, the consumer electronics business. CEBus is viewed
`by many of its developers, including the EIA, as a major commitment to
`help U. S. companies regain a foothold in consumer product manufactur-
`ing. The standard will spur the development of literally hundreds of
`new 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 the
`home automation market to a large number of new product ideas—most
`previously unthought of. You will, undoubtedly, see a host of new prod-
`ucts from many new (and existing) companies that have decided to enter
`the market due to the perseverance of the EIA and the CEBus committee.
`
`Development History
`
`The beginning of CEBus occurred in April 1984, when representatives of
`12 companies attended the first EIA-sponsored meeting in Washington,
`D.C., of the Consumer Electronics Bus Committee (CEBC).
`
`Petitioner’s Ex. 1018, Page 22
`
`

`

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

`

`8
`
`Chapter One
`
`This Book’s Goals
`
`This 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 if
`you plan to develop CEBus products or adapt an existing product. The
`detailed specifications in the standard are essential. Rather, this book is
`designed to make the standard understandable. It provides a technical
`overview for nearly all sections of the standard, and provides implemen-
`tation information that is not available elsewhere. The book provides
`many 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 and
`Brouter communications protocols described in Volumes 5 and 6 of the
`standard. However, because the Router and Brouter protocols are a modi-
`fied subset of the Node protocol, they should be easy to understand
`once you understand the operation of the Node protocol.
`
`How This Book Is Organized
`
`Chapter 2, CEBus Document Overview, provides introductory material
`on the standard, including an overview of the CEBus documents, how
`the standard is organized, the design goals, the design constraints, the
`target environment, and how the goals were achieved. It also contains a
`brief development history.
`Chapter 3, The CEBus Benefit, details some typical applications,
`describes residential network goals and advantages, and what problems
`CEBus solves.
`Chapter 4, CEBus Basics, provides a technical introduction to network
`concepts, terminology used in the standard, and an explanation of some
`of the basic technology adopted in CEBus. You should read this chapter
`before you read Chapter 6, 7, or 8.
`Chapter 5, CEBus Media and Physical Layers, describes the physical
`layer portions of the standard, including network topology, symbol
`encoding, the physical layer interface to each media, and the electrical
`and mechanical requirements of each medium. This chapter covers most
`of the material given in EIA-600.3 (PL/RF Symbol Encoding, Symbol
`Encoding, PL, RF, IR, CX, TP, and Node 0).
`
`Petitioner’s Ex. 1018, Page 24
`
`

`

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

`

`This page intentionally left blank.
`
`Petitioner’s Ex. 1018, Page 26
`
`

`

`7CHAPTER 7
`
`CAL
`
`Copyright © 2001 by The McGraw-Hill Companies, Inc. Click here for terms of use.
`
`Petitioner’s Ex. 1018, Page 27
`
`

`

`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 residential
`product 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 without
`knowing how each specific product operates, who built it, or what’s in it.
`The name CAL is really a misnomer because it is not a formal 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 a
`command syntax that defines the operation of a set of methods on the
`data 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 CAL
`interpreter. The CAL interpreter is an element within the Application
`layer. It provides services to the application, including resource allocation
`and control functions. CAL, in turn, uses the services provided by the
`Message Transfer Element (MT Element) of the Application layer to com-
`municate with other nodes.
`
`CAL Goals
`
`CAL’s design requirements were determined early in its development by
`the CEBus Language Working Group:
`
`It must be common among all residential devices. CAL’s strength is its
`capability to model and control any consumer device found in the
`home through a common set of data structures. These predefined
`data structures ensure application-level interoperability.
`It must allow both control and data acquisition functions. Devices must be
`capable of performing control functions, and to acquire data from
`other devices, either actively by asking for the data, or passively by
`providing a destination for data broadcast on the network.
`It must allow network management administration and management
`functions. All of the “housekeeping” functions required by a node
`
`1When CAL was originally developed, it was intended to be a programming language. The
`purpose and syntax was later changed to a command “language,” but the name stuck.
`
`Petitioner’s Ex. 1018, Page 28
`
`

`

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