This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
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
All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps. McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at [email protected] or (212) 904-4069.
TERMS OF USE This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms. THE WORK IS PROVIDED “AS IS”. McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise. DOI: 10.1036/0071414657
Want to learn more? We hope you enjoy this McGraw-Hill eBook! If you’d like more information about this book, its author, or related books and websites, please click here.
Notable Conventions CEBus CEBus Standard According to guidelines published by the EIA, the trademark “CEBus” is an adjective, not a noun. “CEBus” should always be used with the word “standard,” “compliant,” or other appropriate word since CEBus refers only to the ANSI/EIA-600 standard. A product that complies with ANSI/EIA-600 should be referred to as a “CEBus standard compliant” product, or “CEBus compliant.” However, to make this book easier to read (and to write), the word “standard” is often implied. Wherever the word “CEBus” is used, assume this means “CEBus Standard.” In this book, CEBus, EIA-600, and ANSI/EIA-600 are used to refer to the same official standard: ANSI/EIA-600
Conflicts with the CEBus Standard If there are any differences between the information in this book about the CEBus Standard and the information contained in ANSI/EIA-600, the information in ANSI/EIA-600 should prevail.
What Is CEBus? Why Residential Networks? Why Make a Standard? CEBus Development Goals Development History This Book’s Goals How This Book is Organized
2 3 5 6 6 8 8
CEBus Document Overview
11
EIA-600 EIA-600 Attributes The Standard Parts An Introduction to EIA-600 Parts The Physical Layers The Protocol The Language The Design Constraints Security Issues
12 12 13 16 16 17 18 19 20
The CEBus Benefit
23
The Benefits of Networked Products What CEBus Products Say Control Messages Status Messages Typical CEBus Applications The Future Potential The Plug-n-Play Concept Interoperability Defined Communications Level Interoperability Application Level Interoperability Scenario Interoperability
How CEBus Works—An Overview The CEBus Product Model Nodes Network Communications Models Network Control Model CEBus Reference Architecture and Media Channels Packets and Messages Symbol Encoding Network Attributes CAL:What CEBus Products Say to Each Other CAL View of Products
36 36 37 40 41 42 44 47 48 50 51 51
The Media and Physical Layers
53
The CEBus Network Topology Architecture Assumptions Node O Router and Brouter Requirements Medium, System, and Global Networks Connection to the Outside World The PL Network Power-Line Topology CEBus Signaling on the PL Packet Encoding Physical Layer Implementation PL Performance The TP Network TP Cable and Wire Use TP Control Channel TP Physical Layer The CX Network The Cable CX Network Topology Cable Connectors and Outlets Node O Distribution Device Coax Control and Data Channels CX Physical Layer CEBus RF CEBus RF Signaling
Contents RF Control Channel Encoding RF Physical Layer
Chapter 6
Protocol A Little Protocol Background CEBus Protocol Overview The ISO vs. CEBus Model The Peer-to-Peer Layer Model Transmission Failures Application Layer vs. the Application Packet Format Layer Responsibilities Application Layer The APDU Header Basic Service APDU Extended Service APDU Basic Service Details Explicit_Invoke Service Synchronous Service and the Invoke_IDs Reject APDUs When to Use What Service Application Layer Extended Services Authentication Authentication Algorithms Encryption Using Secure Services Network Layer The NPDU Header Network Layer Extended Services More on IR/RF Packets and Duplicate Rejection IR/RF Packet Examples ID Packets Data Link Layer DLL Structure Packet Format EOFs, EOPs, and Leading Zero Suppression Channel Access Protocol DLL Packet Delivery Services Unacknowledged Service Addressed Unacknowledged Service
Addressed Unacknowledged Sequence/Address Association Acknowledged Service The Physical Layer The PL and RF Medium SES CEBus Addresses The System Address The Node Address Acquiring and Keeping Addresses Implementation Issues Layer System Management
147 148 154 156 157 157 158 160 160 161
CAL
163
CAL Goals How CAL Models the Consumer Product World The Context Data Structure Contexts Objects Object Definitions Context Data Structure Object Network Types Object Binding: How Contexts Work Together Context Examples The Universal Context Context Control Object Determining Product Capability Where Do Contexts Come From? Messages: Object Communications Command ASDUs Response ASDUs Methods Message Generation Implementation Example Resource Allocation Address Resources and Address Allocation Node Addressing Address Self-Acquisition The CAL Interpreter Transporting Non-CAL Messages Generic CAL (ANSI/EIA.721) Differences between Generic and CEBUS CAL
HomePnP Overview Some New Ideas Interoperability and HomePnp State Vectors Configuration Additional Problems Addressed by HomePnP
220 222 223 224 225 225
Product Development
227
Design Considerations for Networked Products Security Addressing Interoperability Partitioning of Processing Tasks Creating CEBus Applications: An Overview The Design Problem Getting It Built Product Benefits Minimum Requirements—Deciding What to Implement Data Link Layer Network Layer Application Layer CAL Certification (ANSI/EIA-633) Plug Lab
Common Object IV Labels Manufacturer IVs Object Tables Object Categories Table Notes 03 Data Channel Receiver 04 Data Channel Transmitter 05 Binary Switch 06 Binary Sensor 07 Analog Control 08 Analog Sensor 09 Multiposition Switch
251 252 252 252 253 254 255 256 256 257 258 259
xii
Contents 0A Multiposition Sensor 0B Matrix Switch 0F Meter 10 Display 11 Medium Transport 13 Dialer 14 Keypad 15 List Memory 16 Data Memory 17 Motor 19 Synthesizer/Tuner 1A Tone Generator 1C Counter/Timer 1D Clock
Chapter One In April 1984, 12 people representing 12 member companies of the Electronics Industries Alliance (EIA) met in a hotel room in Washington, D.C. They were there at the invitation of the EIA Consumer Electronics Group to help formulate some form of common communication standard for consumer devices used in homes. This standardization effort was a result of an earlier attempt to develop a common infrared remote control standard. If these 12 men had any idea that they were about to begin a task that would occupy a considerable portion of their lives—and the lives of dozens of others—for the next 10 years, it is unlikely that they would have continued the task. But, of course, they could not possibly have known what they were about to undertake. What these people started is known as the Consumer Electronic Bus (CEBus) home automation communication standard—a standard that defines a communications protocol, language, and media interface specification that enables any device in the home to communicate with any other device. The CEBus effort, which culminated in 1992, was an impressive accomplishment. No other standard-setting activity that the EIA has ever undertaken approaches CEBus in scale and complexity. More than 400 people and companies were involved in the successful development of CEBus. You are about to reap the benefits of their effort!
What Is CEBus? CEBus (pronounced “see-bus”) is the common name for ANSI/EIA-600, a communications standard for residential consumer products. The standard specifies how products send and receive information, the media available to use the products, and what products say to each other. CEBus solves the traditional problems of integrating products and systems made by different manufacturers by establishing a standard, reliable interface to each CEBus-compliant product in the home. The standard provides A standardized physical interface between devices in the home so that information can be easily and reliably exchanged A standardized way for devices to interoperate and “talk” to each other using a common language
3
Introduction
CEBus enables stand-alone products to become networked products, sharing information and product “resources.” Its standardized common language ensures built-in interoperability and a rich set of capabilities. CEBus also establishes a unified, high-quality cabling standard to handle all of the data communication needs of the home (audio, video, CEBus product communications, computer data, etc.) for the foreseeable future. The cabling standard has become the basis for all current residential infrastructure wiring products and was the basis of the revised ANSI/TIA/EIA-570A residential wiring standard.
Why Residential Networks? During the 1990s, there was a growing need to solve a related set of communication problems in the home. These problems are the result of new technology products in the home (such as home computers, home automation systems, home theater, energy management systems, and telecommunication products) and the rise of wideband service providers. Deregulation of the communication industry in the United States has created new market opportunities for service providers to offer access to a host of wideband information “services.” Cable TV companies can now provide telephone and other high speed two-way communication services. Telephone companies can provide cable TV services such as pay-per-view movies and information services, as well as voice and data communications. Utility companies can provide appliance monitoring and energy management services, and can offer variable electric rates based on their access to and ability to control in-home appliances. These new technologies depend on reliable communications in the home. Present residential wiring will not be capable of providing these services due to the poor quality of most existing in-home telephone and coaxial cable. A new residential network technology is needed. The network must provide three things: A universal, low-cost method for devices in the home to communicate regardless of manufacturer. There must be a way to distribute control and data about the operation of appliances and systems throughout the home. This information allows products to interoperate— sharing information such as time and temperature, the current electric rate, house occupancy, and so on. Without this capability, there can never be a reasonable market for home automation.
4
Chapter One A reliable way to provide for in-home distribution of wideband (wide area network) outside services. Wideband services can be broadly categorized as part of the “information superhighway.” These services include delivery of digital telephony, pay-per-view video, interactive gaming, electrical load management, “house sitting,” computer network access, and the like. These services will arrive at the home via the local cable company, the telephone company, the power company, and wireless (RF) service providers. Many of these services require bandwidths that are not supportable with the present wiring (telephone, cable) in the majority of homes. A reliable way to distribute wideband services that originate from products in the home. There must be a way to distribute in-homegenerated information. This includes video and data from multimedia computers, home theater equipment, VCRs, security cameras, audio equipment, and the new generation of high-tech “set-top boxes.” Audio and video distribution is becoming increasingly important as consumers become more media oriented. CEBus meets all of these needs by forming a local area network in the home for the distribution of in-home and outside data and services. The network has these characteristics: Provides for distributed rather than centralized control Supports the distribution of audio, video, and data, as well as control messages Uses a variety of physical transmission media Provides a flexible application language Enables very-low-cost implementations that are intended for consumer products CEBus delivers a common product interface and a common network infrastructure. It specifies completely the use of the power-line wiring (PL), radio frequency (RF), and infrared (IR), and the installation and use of twisted-pair (TP) and coaxial (CX) cable. The standard is flexible enough to allow CEBus compliant products to be used in existing homes using the PL, RF, IR, and most existing TP wiring. The standard completely specifies how products connect to the network and the communications protocol.
5
Introduction
Why Make a Standard? The committee members understood that future consumer products will be interconnected and that future capabilities will demand access to data and control information from outside the home and between products in the home. A standard for product interconnection is inevitable to future consumer product growth. So, why make one from scratch? Standards arise from a dominant usage of an existing technology— some dominant product manufacturer establishes a technology and other companies copy it—or from a standards-setting organization (EIA, IEEE, or ANSI) at the request of an industry group of companies. In the case of a residential product standard, one that interconnects all products in the home, there is no one product category that could dictate a standard, similar to how IBM and Microsoft standardized the personal computer industry. There are too many unrelated product categories. Because no one product manufacturer is dominant enough to generate a de facto standard, it had to come from a standards organization. To establish a standard from “scratch,” it is essential to set the requirements up front and ensure that there is agreement from all participants before undertaking the technical details. The three requirements for CEBus that were established early in the process are: 1. To allow introduction of new products and services to homes at minimum cost and confusion to consumers. This is the whole point of CEBus. It is designed to remove the entry barrier for products that can communicate. The standard opens the potential for hundreds of new products and services for the homeowner, but it must do so without causing confusion in the marketplace. If the committee on the CEBus technology used a litmus test, it is the test of “…minimum confusion to consumers.” A reliable network technology that is installable by the average homeowner is difficult. Some confusion is inevitable, but every effort was made to minimize any additional confusion. 2. To meet the majority of anticipated home control and information distribution requirements with a single multimedia network standard. CEBus had to handle the control requirements of all existing appliances and products in the home, as well as any future device that manufacturers might think up. It must be usable on any or all of the media present in the home, such as the power line or
6
Chapter One telephone wiring. It must handle the bandwidth requirements for distribution of outside services to any device in the home. 3. To minimize the redundancy of control and operation methods among products in the home. In theory, CEBus can actually simplify the operation of appliances and products in the home by enabling a common interface to develop. For example, CEBus has the capability to enable a television to present menus to allow setting of thermostats, microwave ovens, VCRs, security systems, and the like, with a common onscreen interface. To meet the requirements for CEBus, the technical goals for the technology were clear: it must be retrofittable; it must support distributed intelligence; it must not be product specific; it must have an open architecture; and it must be expandable. The goals were met by IS-60, and products demonstrating the capability were built.
CEBus Development Goals A stated motivation for developing CEBus is to encourage new companies to enter, or reenter, the consumer electronics business. CEBus is viewed by many of its developers, including the EIA, as a major commitment to help U. S. companies regain a foothold in consumer product manufacturing. The standard will spur the development of literally hundreds of new consumer products, and provide an opportunity for small and startup companies to get into (or back into) the consumer electronics business. By providing an open yet controlled standard, CEBus opens the home automation market to a large number of new product ideas—most previously unthought of. You will, undoubtedly, see a host of new products from many new (and existing) companies that have decided to enter the market due to the perseverance of the EIA and the CEBus committee.
Development History The beginning of CEBus occurred in April 1984, when representatives of 12 companies attended the first EIA-sponsored meeting in Washington, D.C., of the Consumer Electronics Bus Committee (CEBC).
Introduction
7 1984—During that first year, the basic scope of the “bus,” as it was called, was established and the major work tasks were assigned to a set of working groups. 1985—The committee started work on a field-test program to determine the characteristics of residential power-line wiring systems by taking actual measurements from hundreds of homes throughout the country. A Language Working Group was formed to begin work on a common product command language. 1986—The committee adopted Homenet (GE’s power-line protocol that GE had developed for HomeMinder) for the foundation of the CEBus protocol. “CEBus” became the de facto name for the standard. 1987—Early versions of the PL physical layer were built using the 1 Kbps ASK technique and preliminary testing was performed in several houses. 1988—In early 1988, the committee decided to demonstrate CEBus in a booth at the 1989 Winter Consumer Electronics Show. The first pass of the language protocol and PLBus physical layer specification was completed. 1989−1990—The first versions of the TPBus, CXBus, SRBus, Node 0, and Application Layer documents were completed. The ASK PLBus and protocol specifications were released for industry ballot, marking another major milestone. 1991—The Intellon spread-spectrum transceiver technology was selected to officially replace the existing ASK PLBus standard. The new PL specifications were completed in draft and released for ballot. 1992—On November 6, the CEBus Committee held its sixty-seventh meeting in Victoria, B. C., Canada. IS-60 became an official EIA document. 1993—The EIA incorporated the CEBus Industry Council (CIC) to serve as a cross-industry association for companies developing CEBus products and services. 1995—IS-60 underwent a final review of changes in an effort to become a joint ANSI/EIA standard: EIA-600. Each part of the standard was reballoted as an EIA-600 document. 1998—Version 1.0 of the Home Plug-and-Play specification was released, incorporating CAL as a standard interoperability language. 1999—The generic CAL specification, providing transport protocol independence, was released as ANSI/EIA-721.
8
Chapter One
This Book’s Goals This book was written to supplement the EIA CEBus standard document. While this book may be all you want to know about the standard, it does not eliminate the need to consult the EIA-600 document if you plan to develop CEBus products or adapt an existing product. The detailed specifications in the standard are essential. Rather, this book is designed to make the standard understandable. It provides a technical overview for nearly all sections of the standard, and provides implementation information that is not available elsewhere. The book provides many diagrams, tables, and explanatory material that will prove beneficial in getting the most from the standard documents. This book covers only the Node communications protocol, the protocol intended for consumer devices. It does not cover the Router and Brouter communications protocols described in Volumes 5 and 6 of the standard. However, because the Router and Brouter protocols are a modified subset of the Node protocol, they should be easy to understand once you understand the operation of the Node protocol.
How This Book Is Organized Chapter 2, CEBus Document Overview, provides introductory material on the standard, including an overview of the CEBus documents, how the standard is organized, the design goals, the design constraints, the target environment, and how the goals were achieved. It also contains a brief development history. Chapter 3, The CEBus Benefit, details some typical applications, describes residential network goals and advantages, and what problems CEBus solves. Chapter 4, CEBus Basics, provides a technical introduction to network concepts, terminology used in the standard, and an explanation of some of the basic technology adopted in CEBus. You should read this chapter before you read Chapter 6, 7, or 8. Chapter 5, CEBus Media and Physical Layers, describes the physical layer portions of the standard, including network topology, symbol encoding, the physical layer interface to each media, and the electrical and mechanical requirements of each medium. This chapter covers most of the material given in EIA-600.3 (PL/RF Symbol Encoding, Symbol Encoding, PL, RF, IR, CX, TP, and Node 0).
Introduction
9 Chapter 6, CEBus Protocol, describes the network protocol used by CEBus. This chapter provides an overview of the protocol requirements and of the basic attributes of the protocol used by CEBus, and covers the requirements of each nonphysical protocol layer (Data Link, Network, and Application). This chapter covers most of the material in EIA-600.4. Chapter 7, CAL, provides a complete description of the CEBus language. The chapter describes how to use CAL, what products say to each other, how messages are generated, CEBus product interoperability goals, and the design requirements of a CAL language interpreter. This chapter covers most of the material given in EIA-600.8 (CAL Language). The chapter also includes an overview of the generic CAL specification (ANSI/EIA-721). Chapter 8, Interoperability and HomePnP, provides an overview of the theory of interoperability, describes some of the problems inherent in product interoperability that CEBus does not address, and discusses how the Home Plug-and-Play specification resolves these problems. Chapter 9, Product Development, discusses the development process of making a CEBus-compliant product, including networked product considerations. This chapter uses what was learned previously in the book to convert a traditional stand-alone product into a CEBus network product. The Appendix contains reference material on the protocol and CAL. A list of CEBus resources (trade associations, manufacturers, consulting companies, and so on) is also given.
Chapter 2 This chapter introduces the standard documents and provides the necessary background material to understand why the standard is the way it is, and why certain design tradeoffs were made. The design constraints of the residential environment set many design and operating limits on the complexity of CEBus. The design goals and the design constraints often conflicted, thereby limiting the CEBus capability. However, nearly all goals were met and the standard provides a high-speed, reliable communication network for a wide range of products in the home.
EIA-600 The CEBus standard was developed by the Electronics Industries Alliance (EIA). The EIA is one of the oldest trade organizations in the United States, and is responsible for many of the consumer and commercial standards used by electronics industries throughout the world (for example EIA-232, EIA-485, telephone, television, radio, and audio standards). CEBus is available for purchase, as are all EIA standards, from Global Engineering as a two-volume set (see the Appendix for address and number). CEBus is just a document. While it specifies how all parts of the network are built and installed, it is neither hardware nor software, nor does it describe how to build hardware or software. There is no such thing as “a CEBus.” There are only CEBus-compliant products and devices. Manufacturers create or adapt existing products to comply with the hardware and software portions of the standard applicable to their product.
EIA-600 Attributes EIA standards are usually written as open, performance specifications, and EIA-600 is no exception. EIA-600 was written using three EIA criteria: It is a performance specification. The standard describes how CEBus devices must perform, not how they are built. The standard gives only the electrical and timing specifications of a CEBus device as seen from the network. The performance specifications are written in terms of the packet content, transmission timing, protocol performance, and network electrical and physical characteristics.
CEBus Document Overview
13
It is open and nonproprietary. Open means that the development, review, and modification of the standard is available to anyone with a legitimate business interest in the technical accuracy and usability of the standard. More than 400 companies have contributed to the development of CEBus. These companies have a tremendous influence on the development of capabilities, operation, and so on. You can also participate in the continued refinement and support of the standard. The diversity of supporting companies contributes to the strength of CEBus. It is a minimum requirement for compatibility. The CEBus standard describes those features and capabilities that must be implemented for products to communicate reliably in the home using the CEBus protocol. It allows for easy extensions as needs change and future product categories are invented. It allows wide flexibility in implementation. Manufacturers are free to meet the standard using any combination of hardware or software, and by using existing or new components.
The Standard Parts The CEBus standard can be divided into three major areas: the physical media and media topology (power line, coax, twisted-pair, and so on, and how they are connected); the communication protocol (used for network access and constructing messages); and the communication language (allowing devices to communicate using a common set of commands). The standard is divided into eight volumes, and volumes are divided into numbered parts. The description of each volume in the following paragraphs gives the EIA-600 volume/part number. EIA-600.10 Introduction This volume covers the overview, background, scope, and goals of the standard. It also includes a set of minimum requirements for CEBus-compliant products, and a set of word usages and global definitions for the entire standard. EIA-600.20 Description This volume provides an overview description of the EIA-600 standard starting with the general architecture; a discussion of the media and topologies used with each medium; and an overview of the message protocol and command language used by
14
Chapter 2 all EIA-600 devices. As of the publication of this book, this section was still incomplete. EIA-600.30 Physical Layer and Media This volume consists of nine parts covering all of the EIA-600 allowed media and the physical layer interface to the media (OSI Layer 1), plus a discussion of all network support functions, including Router and Brouter physical layer descriptions. EIA-600.31 PL, Physical Layer. Describes the physical layer interface requirements for connection and use of the residential power-line wiring. EIA-600.32 TP Physical Layer. Describes the physical layer interface requirements for connection and use of twisted-pair cabling, including the telephone wiring. EIA-600.33 Coaxial Cable Physical Layer. Describes the physical layer interface requirements for connection and use of a coaxial cable network. EIA-600.34 IR Physical Layer. Describes the physical layer interface requirements for use of infrared as a single-room communications medium. EIA-600.35 RF Physical Layer. Describes the physical layer interface requirements for use of RF as a whole-house communications medium. EIA-600.36 Fiber Optic Physical Layer. Currently not used. EIA-600.37 Symbol Encoding Sublayer. Describes the requirements for network symbol encoding for the twisted-pair, coax, and infrared physical layers. The symbol-encoding sections are considered a “sublayer” of the physical layer. EIA-600.38 PL/RF Symbol Encoding Sublayer. Describes the requirements for network symbol encoding for the RF and PL physical layers. EIA-600.39 Node 0. Describes the physical network support functions for power, twisted-pair, and coaxial cable. EIA-600.40 Node Communications Protocol This volume consists of six numbered parts covering a complete description of the OSI protocol layers used by EIA-600 and the resulting message packet format. EIA-600.41 Data Link Layer Descriptions. Describes the requirements and functions of the Data Link portion of the protocol. The Data Link layer is divided into two sublayers: the Medium Access Control sublayer, and the Logical Link sublayer. EIA-600.42 Medium Access Control Sublayer. Describes the functions of the Medium Access Control sublayer in terms of a state machine
CEBus Document Overview
15
and its interface to the Logical Link sublayer and Symbol Encoding sublayers. EIA-600.43 Logical Link Sublayer. Describes the functions of the Logical Link sublayer in terms of a state machine and its interface to the Network and Medium Access Control sublayer. EIA-600.44 Network Layer Description. Describes the requirements and functions of the Network portion of the protocol. EIA-600.45 Network Layer. Describes the function of the Network layer in terms of a state machine and its interface to the Application layer and Data Link layer. EIA-600.46 Application Layer. Describes the functions of the Application layer and the state machine and layer interfaces. The Application defines the interface to the user application (or user element) and the Network layer. While the Application layer formally includes the CAL language interpreter function, it is described in a separate document (EIA-600.08). EIA-600.50 Router Communication Protocol This volume consists of four parts covering a complete description of the OSI layers necessary to implement a Router function between EIA-600 physical media. EIA-600.60 Brouter Communication Protocol This volume consists of four parts covering a complete description of the OSI layers necessary to implement a Brouter function between EIA-600 nonphysical media (RF, IR) and physical media. EIA-600.70 Supplemental Data This volume is reserved for any future “supplemental data” found necessary to use or understand the standard. It is presently not used. EIA-600.80 Common Application Language This two-part volume covers the high-level command language (CAL) used by all CEBus-compliant devices. EIA-600.81 CAL. This part describes the data structure and message syntax of the CAL language. It also covers the interface to the rest of the application layer. EIA-600.82 CAL Contexts. This part furnishes the four general CAL Contexts (Universal, Data Channel, Time, and User Interface). The remaining contexts are the published Home PnP (Home Plug-and-Play) specifications (see Chapter 8).
16
Chapter 2
An Introduction to EIA-600 Parts The following sections introduce the three major parts of the standard: physical layers, protocol, and language.
The Physical Layers EIA-600.30 describes the media used by CEBus, how CEBus devices connect to and transmit on the media, and the signaling technique used on each media. While the communication protocol and language are common to all CEBus devices, the installed media and topology may vary considerably from home to home depending on the needs and types of devices used in the home. Devices can connect to and communicate over any (or several) of the following media: The existing 110/220V power-line (PL) wiring of the home accessible by devices that normally plug into an electrical outlet. A four twisted-pair (TP), or four-pair, cable that can be used by CEBus-compliant devices that normally use low-voltage wiring (thermostats, security sensors, and the like), and communication products (telephones and intercoms). The four-pairs (called TP pairs) can be used in place of the normal telephone wiring or can supplement existing wiring. The pairs in the cable are named TP0, TP1, TP2, and TP3. CEBus distributes DC power (18 volts) on TP0 to power devices that attach to TP such as thermostats or sensors. The new Telecommunications Industry Association telephone premise wiring standard and CEBus TP wiring are designed to be compatible. A pair of coaxial (CX) cables used by CEBus devices normally connected to video cable such as TVs and VCRs. The coax pair delivers CEBus messages, cable TV programming, and in-homegenerated video (cameras, VCRs, computers) to any video device in the home. One cable in the pair is dedicated to externally provided widebandwidth services, and one wire is used to distribute in-home-generated signals. Radio frequency (RF) communications throughout the home centered at 915 MHz. Infrared (IR) communications for line-of-sight distances (usually single room) using IR wavelengths similar to hand-held remotes.
CEBus Document Overview
17
Due to the wide choice of media, existing homes can begin using the standard as easily as new homes. An existing home can immediately use the power line for new CEBus devices, and the devices obviously require no installation tasks. As a family becomes comfortable with the technology and comes to rely on CEBus products, additional media can be retrofitted if desired. New homes can begin to take advantage of the new and CX capability. The TP wiring requires a four-pair twisted telecommunications cable (good quality telephone wire). Homes wired to the new telephone industry wiring standard (TIA-570) will be CEBus ready. The CX media standard requires the installation of a pair of coaxial cables (equivalent to RG-6), branched from a central location to each room or area in the home. The standard classifies the media into two groups: wired and nonwired media. The wired media are PL, TP, and CX. The nonwired media are RF and IR. The different medium networks connect by devices called Routers and Brouters. A Router is a two-way CEBus device that connects any two wired media (PL to TP, PL to CX, or CX to TP). Messages that originate on one medium are routed to the other connected medium. A Brouter is a two-way CEBus device that connects a nonwired medium to a wired medium such as RF to PL. Messages that originate on RF or IR are routed to a wired media. Routers and Brouters are required to make the different media used in a home appear to each CEBus device as one medium. If a CEBus device transmits a message, it must reach all other CEBus devices in the home, regardless of the medium used.
The Protocol EIA-600.40 describes the Node Communications Protocol. The network protocol used by CEBus is based on the ISO Open Systems Interconnect (OSI) seven-layer network protocol model. A protocol defines the format of the data, or “packets,” sent and received by network devices; the access to the physical network media; and the services provided by the protocol, such as error detection, reception acknowledgment, priority, and so on. The protocol is defined in six parts that detail the operation and requirements for the three network layers used: Data Link, Network, and Application. Each layer represents a division of responsibility of the protocol, and follows the divisions established by the OSI standard for protocol tasks.
18
Chapter 2 The Data Link layer (DLL) is responsible for the low-level task of reliable message delivery on a single medium—the medium used by the device. It handles error detection, packet retransmission, address recognition, packet timing, and buffering. The DLL is defined in two separate documents: the Medium Access Control sublayer (MAC), and the Logical Link Control sublayer (LLC). These documents divide the DLL responsibilities into separate parts, although this is only a documentation convenience. The MAC handles most of the layer tasks; the LLC is little more than an interface with the Network. The Network layer is responsible for reliable message delivery across network media. It handles medium selection, routing, and duplicate packet rejection for packets that originate on a nonwired medium. The Network layer also is responsible for message flow control; it ensures that a long message that is divided into several shorter messages arrives at its destination in the right order. The Application layer is responsible for message generation, reception, and execution. The Application layer uses an end-to-end acknowledgment service to determine that a message sent to another node is received and executed, and that any required result is returned. The Application layer contains the CAL language parser and interpreter, and the interface to the products application “element”—the application hardware or software that operates the product.
The Language EIA-600.80 describes the Common Application Language (CAL). CAL is an element, or part, of the Application layer, but because the description of CAL is rather lengthy, it is given its own separate volume. The CAL specification defines the message structure, syntax, and data structure necessary to model and control any consumer product operation. The description of CAL is divided into two separate parts. Part 1 defines the message structure, syntax, and capabilities of the language. Part 2 defines the major data structures, called Contexts, that define specific functions of consumer products. The most general Contexts are supplied as part of EIA-600. The remaining industry-specific Contexts (HVAC, security, lighting, and so on) are published as separate documents available from the CEBus Industry Council. See Chapter 7 for more information on Context documents.
CEBus Document Overview
19
The Design Constraints The difficulties of designing a residential network that can be installed by a homeowner are immense. To make the task practical, design constraints were imposed on the standard that bounded the difficulties. The scope of the network capability must be adequate to ensure successful consumer operation, yet be low cost and simply implemented. The following are the major resulting design requirements and constraints. A CEBus network may be installed—unknowingly—by family members. This is, by far, the most severe design constraint. CEBus products are usually purchased one at a time, brought home, installed by the homeowner, configured in some way, and expected to work. No network engineer is employed by the family. It cannot be known in advance what products will be installed or the order of installation. Dealers or custom home installation specialists may be used when a home automation system or a home theater is being installed, but the standard is developed as though these services are not available. The requirement to have products work correctly without the assistance of a specialist is still a concern of the Interoperability Working Group of the CEBus committee and the CIC. CEBus products may be installed by knowledgeable installers such as the companies that install security systems, heating and air conditioning equipment, or custom entertainment equipment. These avenues of installation are an important part of the early market usage, and in the installation of products requiring more than plug-and-play skills. However, the standard must be able to support installation of plug-and-play products by the consumer (such as toasters, clocks, and CD players). The installer/user of the network is unskilled. The typical homeowner is not a network engineer. The network must be installable and usable by anyone in the home. Even if the original installation was done or assisted by a trained specialist, products will be added by the homeowner. There is no preconceived network. It is not possible to know what wiring is available in the home or what medium will be used for installed CEBus devices. Provisions must be made to allow any medium in the home that meets the standard to be used.
20
Chapter 2 CEBus is primarily a residential network. CEBus is a home network standard, designed to handle typical residential consumer products and systems, using the media available in the home. Specific commercial requirements (large size, harsh environments, and the like) were not considered. While CEBus is certainly capable of being used in commercial environments—and is being used in offices and malls—it was designed primarily for the needs of residential products. CEBus must be fast enough to handle existing residential tasks. Network message delays must be kept to a minimum, typically less than 0.1 second. This is considered the longest time delay allowable from the time a light switch is toggled until the light turns on or off— a real time-sensitive event for consumers. Messages must also have a priority scheme that allows high-priority messages to get through faster than noncritical messages. Yet, no one device can dominate the network. All CEBus devices must be guaranteed network access. Network “troubleshooting” will be difficult. Network troubleshooting— regardless of the network—is always difficult. If the network develops trouble, if CEBus products fail, or if the network is damaged, it will be almost impossible for the homeowner to determine the fault without the assistance of extra equipment, diagnostic tools, or outside help. For this reason, high reliability and fault tolerance are part of the design criteria.
Security Issues The security of any network (residential, commercial, or industrial) is always a concern, particularly as more people acquire technology allowing easy network access. While CEBus networks are limited in scope to one house or apartment, there is concern over possible access to the network from outside “malicious” users, as well as from in-home “hackers.” The concern is valid because several users of the network—such as electric utilities, telephone, and cable companies—may pass rate and usage charge information over the network. The standard does not attempt to protect the network from intentional malicious access. It is possible for someone or some device to “jam” one or more of the medium networks in a home, preventing any
CEBus Document Overview
21
message communication. However, this is true of any existing home technology, such as security systems (particulary RF systems), telephone, cable TV, and the like. The standard provides a compromise between the need for high security and the requirements for low-cost implementation. While access to the network is difficult to control, an optional software technique is specified in the standard to allow devices to employ a combination of message authentication and/or message encryption. Message authentication requires both the sender and receiver of a message to possess a set of security “keys.” The message is readable, but the authentication algorithm prevents an unauthorized user from generating the same or similar message. Message encryption can also be employed, using the same set of keys, to prevent the message from being read. Both authentication and encryption are optional security features, and only devices that absolutely need the level of security provided by the techniques (electric meters, cable TV boxes) need to implement the extra software.
Chapter Three When I explain CEBus to those not familiar with the technology, or to the press, I usually get the question: “But what does a toaster say to a television?” It’s a good question, but a better question—never asked—is, “Why would a toaster want to say anything to a television?” After all, what benefit could there be in having a toaster communicate with anything? The answer is twofold: 1. The toaster—or thermostat, hot tub, VCR—can rely on the resources or features of the TV without having to have these resources built into the toaster. 2. The toaster can do more. Once the toaster has access to other products, it can use the features of those products “for free.” It may announce that the toast is ready over the intercom; it may operate only when the coffee pot is finished brewing; or it may sound a security alarm if the toast burns. This extra capability can be achieved for a small incremental cost and enable the toaster to command a higher market price.1 The extra capability can also provide excellent marketplace differentiation, particularly in a mature market in which there is little to distinguish one toaster from another, except price.
The Benefits of Networked Products Historically, all consumer products, even computers, were designed to operate as stand-alone products. Everything that a product needed to operate—to be used by the consumer—had to be built into the product. All user interface parts (displays, keypads, and the like), clocks, sensors, memory, setup/configuration information, signal sources—all resources—had to be contained in the product. There was no way to distribute the needed parts between products. Today, almost all consumer products are still designed this way. Although entertainment products (TVs, VCRs, stereo receivers) are intended to operate together, they have to
1
There seems to be a common misconception among consumer product makers (particularly audio/video equipment makers) that consumers will not pay for additional product features. The companies that believe this must not have any experience with the computer industry.
The CEBus Benefit
25
be physically interconnected with a rats nest of specialized wire and are limited to exchanging audio and video signals. Computer products also began as stand-alone products. The personal computer industry started with essentially a series of custom computers. Each computer used a different operating system, a different hardware structure (processor, bus), and peripheral devices were, for the most part, made specifically for each individual computer. Each computer needed everything necessary to provide all the functions it could do: compute, store, print, and display. Today, of course, almost all computer products network together. Interoperation of computer products made by different manufacturers is the rule rather than the exception. Once the networking trend started in the late 1980s, and once users realized its benefits, manufacturers quickly adopted network interfaces for their products. The same will happen to the rest of consumer products, including TVs, thermostats, hot water heaters, and toasters. Ten years from now, only the most trivial of products will operate as stand-alone products. The benefits of networking are too compelling.
What CEBus Products Say CEBus-compliant devices exchange two fundamental types of messages: control messages and status messages. Control messages enable one product to control the operation of another product. Status messages convey information about the status, condition, or sensor value from one product to another.
Control Messages The concept of allowing one product to control another is relatively easy to comprehend. Many products already allow the consumer, to a limited extent, to remotely control other products. An infrared remote control and the garage door opener are typical examples of one product controlling another. Many people enjoy the benefits of the X-10 line of products that allow light switches to be remotely located from the lights they control. CEBus allows any product to acquire the capability to control the operation of any other CEBus-compliant product. This has one immediate benefit to product manufacturers: it allows multiple product operation to be centralized and performed through a common user
26
Chapter Three interface. Typical examples of two products that can take immediate advantage of this benefit are the TV and home computer. Both products provide a potentially simple user interface for other products in the home that are not simple to operate, such as the microwave oven, VCR, clothes washer, programmable thermostat, and security system.
Status Messages CEBus also enables devices to share information about the operation of the home, such as the time, temperature, occupancy state, and status of equipment. The capability to share information allows Redundant product functions to be centralized in one product The removal of the cumbersome user interface from many products An easy delivery method for outside service information Products simply “place” the information on the network, such as the outside temperature, and the information is picked up by products that can use the information to their advantage. Again, the information can originate in the home, or from service providers outside the home. One of the first examples of this feature is the delivery of electric rate information by the electric utilities. CEBus products such as electric water heaters, dryers, and other high-energy-consuming appliances can receive the rate information off the network and delay operation until rates are lower.
Typical CEBus Applications The ability to network products provides a market opportunity for a whole new category of products: resource providers. These products do nothing by themselves; they are like plug-in cards for PCs. They will provide common information or services to other products on the network, or a common hardware or software resource. The simplest of these products will provide a basic piece of information or service to the network such as time, temperature, security status, or house occupancy. A plug-in-the-wall time module is one of the simplest, yet most useful, service providers. This little device, the same size
The CEBus Benefit
27
and shape as a small wall-mounted power supply, simply broadcasts the date and time to any device in the house that needs it. It contains an accurate clock circuit and a backup battery. The advantages of having a common time broadcast should be obvious. Networked products no longer need to have a clock circuit that flashes 12:00 because no one remembers how to set it. There are many more examples of devices that can provide useful network information. A simple outside temperature sensor that broadcasts the outside temperature to products such as a thermostat, a heat pump compressor, exhaust fan, or television. A CEBus-compliant electric meter that provides the current electric rate (as well as future rates), the energy used this month (in kilowatt hours), and the current kilowatts being used by the house. This information can be used by high-energy-consuming appliances such as an electric water heater, pool heater, heat pump, or other appliances that may defer operation until rates are lower or total house demand is lower (to avoid peak usage charges). Chapter 7 describes how products can easily receive any of this network information without requiring any special product configuration when installed. There are also many examples of products that provide resources for other products to use. The most useful of these is the video interface device, more commonly referred to as a TV. A television provides a convenient and potentially easy user interface for the operation of other products that cannot afford to incorporate a good user interface. A thermostat, particularly a programmable thermostat, needs only occasional attention to set or adjust heating schedules, but usually has a poor user interface (a liquid crystal numeric display and a few cryptic buttons). A CEBus-compliant thermostat can allow a CEBus-compliant TV to act as its user interface, providing easy-to-read onscreen menus and instructions. The personal computer is the second most popular user interface device in a growing percentage of homes. While it may not be as convenient (at least for a few more years) as a TV, its user interface capability is more advanced. As more consumers become comfortable with using home computers, its role as a common user interface for home control and management will increase significantly. Computer manufacturers are already building CEBus interface circuitry into their PCs.
28
Chapter Three
The Future Potential As more networked product resources and information become available in the home, a market develops for more complex applications. For example, one of the most difficult yet most useful pieces of information to obtain about a home is whether it is occupied. This information can often be inferred from a security system if the system is armed in an “away” mode. Many homeowners, however, either don’t use their security system or forget to arm it when they leave. Knowing whether the house is occupied must be inferred from a more complex heuristic. Having access to information about the operation of the house available off the network can allow a product to build probability tables about device activity (lights, security devices, even plumbing). A lack of activity, when there is a high probability that there should be activity, may indicate that the house is unoccupied (or that the occupants need medical assistance). Tables of who is home at what times of day can also be created. The inverse information—activity in the house when it is expected to be unoccupied—is easy to obtain. Safeguards can be built into the product to test whether a house is unoccupied (by announcing the house state, placing messages on TVs, and the like) to ensure higher reliability. Even if the occupancy state is calculated accurately 98 percent of the time, the benefits are potentially terrific. As long as no serious action is taken (alerting the police, turning on or off critical appliances), being wrong 2 percent of the time is a minor inconvenience. If a device knows the home is unoccupied, it can provide a valuable resource. It can arm the security system, turn off appliances, set back temperatures, turn off (or on) lights, and, in general, look after things. This may seem farfetched, but prototypes of this function have been used with good success in home automation systems. The difference is that the home automation system had to be purchased and installed as a system and cost tens of thousands of dollars. In a CEBus environment, this capability could be purchased for a few hundred dollars at Circuit City and installed by the homeowner. The occupancy calculator is typical of higher level products that make inferences from the information available on the network. There are many other possible applications given a critical mass of network resources. Fault or malfunction detector. This device looks for fault conditions from products on the network (many CEBus products are capable of reporting fault conditions), for example, a malfunctioning
29
The CEBus Benefit
device such as a smoke detector, or a network problem such as two products with the same address. It then reports the problem to the homeowner via the TV, printer, or by voice synthesis. Emergency “watch dog.” This is a variation of the occupancy state device. It looks for anticipated activity from the house occupant(s). If there is no activity over a period of time, it can place a call to alert a remote family member or a medical service. Network configuration devices. This hardware or software product helps installation and configuration of CEBus-compliant devices using a rich user interface. This application typically runs on a PC and keeps a database of CEBus context use, installed products, and the features of all networked devices. This product also allows the homeowner to configure interproduct scenarios (described in the next section).
The Plug-n-Play Concept For most of the applications described in this chapter to become a reality and easily installed at low cost, it is essential that CEBus-compliant products be plug-n-play whenever possible. The concept of plug-n-play (the contraction of plug-and-play) is basic to a consumer-oriented network technology such as CEBus. Plug-and-play design allows products to access and use information in other products in a uniform way. It allows one product to control another class of product without programming or custom installation tasks. CEBus has the potential to achieve plug-nplay compatibility between a large number of products if the standard is used correctly. The benefits are substantial, but a clear understanding of what the plug-n-play concept means is essential. Plug-n-play implies a level of interoperability that is difficult to achieve in a typical network. Interoperability means the ability of products to work together over a network using a predefined level of interaction built into the protocol. Protocol interoperability is a requirement for achieving plug-n-play products. The term interoperability is often misused because the concept of working together, like plug-n-play, means different things to different people, particularly between manufacturers, developers, and consumers. If a product claims to be interoperable with other products on a network, does that mean that the product knows how to operate other products on
30
Chapter Three the network? How much can it operate? What features are available? What product information is available? Can it tell whether another product is on the network? For CEBus consumer plug-n-play products, interoperability is a primary requirement; thus, it is important to clearly understand what it means. This means understanding how CEBus networks will be built by consumers. The CEBus Committee assumed that CEBus-compliant products will be purchased, brought home, plugged in, and work. Products are purchased incrementally, in any order, and added to over time as new products replace older, nonnetworked, products. This network growth model requires a very high level of product interoperability because it does not rely on any type of central control, or on an installation expert (human or machine). To ensure this level of interoperability, all aspects of product interoperation must be defined. This includes everything from connectors, wire, signaling, and product language, to how products share information. This explains the need for the level of detail present in the CEBus standard document.
Interoperability Defined Because product interoperability is so important to successful use of CEBus, it is important to clearly understand what interoperability means and how it applies at different stages of product development, installation, and use. CEBus product interoperability can be divided into three levels: communications interoperability, applications interoperability, and scenario interoperability.
Communications-Level Interoperability Communications-level interoperability refers to the capability of products to send and receive packets over the network and successfully understand the content of those packets. This requires that all CEBuscompliant products adhere to a proper implementation of the basic CEBus protocol design, including the physical layer and the use of the communicating medium. This level of interoperability is built into the protocol code and into the product network hardware interface. Products must use the protocol to access the attached medium, transmit and receive packets on the medium without interfering with other
The CEBus Benefit
31
devices on the network, and interpret the contexts of the packet successfully. Products must also understand a minimum set of CAL messages. The minimum set includes commands for resource allocation and configuration, as well as commands to access basic information about the product, such as its network address, serial number, and product class. This level of interoperability is fundamental to the technology and adherence is an absolute requirement. The guideline for ensuring communications interoperability is ANSI/EIA-600 where these requirements are clearly defined. Interoperability can only be obtained if the standard is implemented correctly. While this level of interoperability is critical, it is the easiest to test. A product can be subjected to a standardized series of packet reception and transmission tests to ensure that packet format, timing, and protocol usage adheres to the specifications. The CEBus Conformance Specifications (EIA-633) can be used by a manufacturer to ensure that its product meets the minimum protocol requirements for certification.
Application-Level Interoperability Application-level interoperability defines how products know to use (control and share resources and information with) other devices on the network, and is the basis for plug-n-play product design. This is the level that the consumer is most concerned about and where real benefits are achieved. Understandably, this is the most difficult level of interoperability to achieve for two reasons: 1. It requires detailed agreements on the definition of product operation—an area that has previously been the exclusive domain of the manufacturer. 2. It is difficult to test. The basic CEBus tool for insuring application interoperability is the CAL language and its associated context data structure definitions. Contexts establish a standardized data structure for each and every consumer product function. A product implements those contexts that define all of the functions the product is capable of supporting via CEBus. The syntax and operation of the CAL language are defined in EIA-600. The actual context data structures that pertain to real product functionality are defined in separate documents (grouped by industry functional category, such as lighting, audio/video, security, and HVAC).
32
Chapter Three These documents are developed jointly by the CEBus Industry Council and working groups of representatives from companies in each product category. Contexts are designed to be extended as new product functions emerge in each product category. Contexts define how products are “seen” over the network. By reading and writing to variables in the context data structure, a product can be used by another device on the network. The definition for each product function is standardized so that, for example, the audio amplifier function in a stereo receiver is operated in the same way as the audio amplifier function in an intercom or PC. Contexts are designed to allow predefined pairing or “binding” of the contexts in one device with the contexts in another device. The concept is similar to the way hardware functions are distributed over a computer bus. The data output of a device has a predefined context destination in one device or a group of devices. The model also allows devices to broadcast information on the network for use by any other device that can use the information. To receive the information (such as the current electric rate, temperature, or time), a device need only instantiate a copy of the context that receives the information. For example, consider the following situation in which two devices are completely interoperable as far as correct implementation of their Context data structures, yet, they do not communicate: An HVAC equipment vendor makes a temperature-sensing device that provides the current temperature to any device that asks (reads the IV containing the temperature). A different HVAC manufacturer makes a thermostat for use with a remote temperature sensor. This device assumes the temperature sensor will announce its temperature (send a message to a receiving context) each time the temperature changes. Because the thermostat never asks, and the temperature sensor never announces, the two devices do not operate together even though they both use CEBus communications layers properly and both agree on how to represent the temperature in CAL. This problem can be avoided by careful planning and development of the context models.
In principle, context binding can allow many products to interoperate in the home by simply bringing them home and plugging them in (thus, plug-n-play). Little or no consumer configuration of intelligent control is required. A core level of the most common and desirable applications can be achieved by purchasing off-the-shelf products. For most consumers, this basic interoperability will be all that is necessary for many beneficial automation features.
33
The CEBus Benefit
Scenario-level Interoperability Scenario-level interoperability defines how two or more products use CEBus application-level capabilities to cooperate to perform a predefined set of actions in the home. The action is usually initiated by an event such as a time of day, light level, arming or disarming of a security system, and so on. The following scenarios are typical of those possible between CEBusnetworked products: When a homeowner returns home and disarms the security system, the heating temperature is set to 72°, the hot-tub turns on to 102°F, the curtains open in the living room and family room, the TV turns on to CNN, the telephone answering machine is set to answer on the eighth ring (instead of the first ring), and the PC retrieves any waiting email. The utility company sends a broadcast message to all devices containing the appropriate context to receive the current price schedule. When electric rates exceed a predetermined value, the hot tub turns off, nonessential lights turn off, the air conditioning is set 3° higher, the hot water temperature is set 10° lower, and the pool pump stops circulating. When rates drop to previous levels, the process is reversed. Unlike basic application-level interoperability, these scenarios require agreement on the order in which messages are given and on which devices are the senders and which are the receivers of messages. Because a device must be separately programmed to send and receive a specific set of messages, agreement on this subject is important. This kind of interoperability may appear to be unmanageable. However, to some degree, agreements can be achieved on the relative roles of sensing and controlling devices and related system behaviors. These agreements can provide manufacturers with guidelines to achieve interoperability relating to scenarios. The CIC works to achieve these agreements through a consensus of member companies.
Chapter 4 This chapter provides an overview of how CEBus works and introduces the basic concepts and terminology that are used in the remainder of the book. Most of the material in this chapter is discussed in more detail in the next three chapters on the physical media, protocol, and CAL.
How CEBus Works—An Overview CEBus-compliant products work by momentarily “connecting” to another product on the network to perform a sense or control operation. This “virtual connection” is achieved by gaining exclusive use of the medium that connects the two products long enough to transmit a command or request. After communication is complete, the transmitting devices release the use of the medium. The medium can be the power-line wiring, twisted-pair cable, coaxial cable, RF, or IR. The messages are transmitted by either placing a signal on the wire, or transmitting an RF or IR carrier. Messages are short, lasting an average of 25 ms, and contain 50 to 300 bits. By keeping messages short, many devices can share the medium without conflict because messages between any two products are relatively infrequent. To ensure high message delivery reliability, and to ensure that products do not all transmit at the same time, CEBus devices adhere to a strict message protocol. A protocol is a set of rules that define how and when messages are sent, how to recover from transmission errors, the format of messages, and so on. The messages contain commands in a common command language (CAL) that is understood by each product. The command language is specifically designed for information sharing and control of residential consumer products. CEBus-compliant products are required to understand a minimum subset of the command language and that portion of the language specific to their product category.
The CEBus Product Model This section describes the basic assumptions about the design and operation of a CEBus-compliant product.
37
CEBus Basics
Nodes Any CEBus-compliant device attached to a medium is referred to as a CEBus node. A node is any device that Can transmit and receive CEBus packets on at least one medium Adheres to the CEBus message protocol Uses and understands a minimum set of the CAL language The minimum CAL language requirements comprise a common set of network management commands plus commands that are specific to the device category. For example, a CEBus light switch must understand the commands to turn on and off the light, but does not need to understand a command to “turn to channel 13.” All CEBus nodes consist of the three major parts shown in Figure 4.1. This diagram represents a simple internal model of every node. The parts can be implemented using any combination of hardware or software. The PROTOCOL is the same in each CEBus-compliant device and is responsible for reliable message delivery. The protocol software defines the format of the transmitted packets, the packet delivery “services” (error detection, message priority, retransmission of lost messages, responses to messages), and the technique for accessing and transmitting messages on each medium. The CAL portion of the model is responsible for converting product application events into a CAL language message—or “words”—that other CEBus nodes understand. Likewise, it interprets received messages and affects product operation.
Figure 4.1 Simple CEBus product model.
38
Chapter 4 The APPLICATION represents the specific node application for the product, and contains the hardware and software that define the product operation. Figure 4.2 shows the model in terms of the formal protocol layers that define node operation. The protocol software consists of four layers or subfunctions: the Physical layer, the Data Link layer, the Network layer, and the Application layer. The CAL interpreter is formally part of the Application layer. A Message Transport sublayer, also part of the Application layer, provides many of the services traditionally found in a protocol Session and Transport layer. Figure 4.2 highlights the major tasks performed in each layer. Figure 4.3 shows the model in block diagram form. The I/O and application routines handle the interface of the device hardware and application software to the Context data structure and the protocol routines. The Application reads and writes the context data structure to reflect prod-
Figure 4.2 Product model in terms of the protocol layers.
Product Application
APPLICATION LAYER CAL interpreter Context data structure MESSAGE TRANSPORT SUBLAYER Message authentication/encryption End-to-end acknowledged service NETWORK LAYER Intermedia routing Segmented service/flow control DATA LINK LAYER CSMA protocol Error detection, retransmission DL acknowledged service PHYSICAL LAYER Medium interface Symbol timing/encoding Superior/inferior state generation Medium
CEBus Basics
39
Figure 4.3 Block diagram form of product model showing division of Protocol, CAL, and Application.
uct operation. The context data structures serve as the interface from the CEBus network to the product resources. The application can generate messages by writing to the Context data structure, or by forming a message “manually” and passing it to the Message Transport sublayer (responsible for receiving and generating messages). The Context data structure represents a software model of the product’s operation to the rest of the network. The CAL interpreter translates changes in the context data structure to an appropriate message to another node. Received messages are interpreted and the context data structure is updated accordingly. Formally, the CAL interpreter and its associated Context data structures are part of the protocol stack—the Application layer—but considering the interpreter as the protocol application is convenient because its function is unique to CEBus. The CEBus standard and this book treat the CEBus protocol as the Physical layer through the Message Transport sublayer. The protocol is covered in detail in Chapter 6. CAL is treated as the CEBus application and is covered in Chapter 7.
40
Chapter 4
Network Communications Models Every communications protocol makes assumptions about the hierarchy of device-to-device communications in terms of network access control and device control. To gain a better insight into the design of the CEBus protocol layers, it is helpful to know the CEBus design assumptions. The CEBus protocol uses a peer-to-peer communications model (Figure 4.4). This means that the protocol is designed to enable any node on any medium to communicate (send and receive messages) with any other node in the home. There is no communication hierarchy or restrictions on product-to-product communications over any media. This communications model is essential if CEBus-compatible products are to be installed in the home incrementally. As devices are added to the network, they must be able to communicate with any existing products. There can be no assumptions about the order or the type of devices added to the network. The communications model also assumes that there is only one CEBus medium shared by all nodes. Though many physical media types are used (twisted-pair, coaxial cable, RF, and the like), they are treated as a single medium, and any message generated by any node will arrive at all other nodes on the medium. The various physical media are interconnected by Routers and Brouters, which are described in more detail in Chapter 5. The job of Routers and Brouters is to make the different media behave as one medium to the connected nodes. CEBus uses a connectionless service protocol. This means that devices gain access to the network media only long enough to transmit a message and then get off. Because messages are short, many devices can share
Figure 4.4 CEBus communications model. Each product communicates on a peer-topeer level with all other products. There is no communications hierarchy.
41
CEBus Basics
the medium. No connection is formed between two communicating devices and the network is not tied up during their “conversation.” This is different from a typical connected service network such as the telephone network in which two nodes establish a communication connection and retain exclusive use of the media until all conversation is complete, then hang up, releasing the network resources for another call.
Network Control Model The protocol supports two control models (Figure 4.5). A control model defines which nodes can control other nodes on the network. The CEBus protocol assumes a peer-to-peer distributed control model, allowing any node to control any other node. This is also a result of CEBus networks being built incrementally and in random order. Any product can control any other product in the home, if it is capable of doing so. No type of central control device or automation system is necessary in CEBus. The absence of central control was a development goal of the standard. Products may be added anytime by the homeowner without having to notify or program a central system. While CEBus is not dependent on central control, it does not exclude it, or the most common variation, the cluster control model. Cluster control allows one or more nodes to assume the task of controlling several other nodes. This model is employed for system-oriented products in the home, such as HVAC systems, security systems, and lighting control systems, and it is the model used by these systems for control by people. To set the temperature in the downstairs air conditioning zone to 69°F, a user might use an onscreen menu on the living room television. The television would send a message to the downstairs thermostat requesting a new temperature. The thermostat, in turn, would send the necessary control (over TP) to the HVAC air handling unit, compressor, motors, and
Figure 4.5 CEBus control model. CEBus allows combinations of distributed and cluster control. Product clusters are assumed to be controlled by one node.
42
Chapter 4 so on, required to achieve 69°F. The television could send messages directly to the HVAC air handler, compressor, motors, and so on, but it would not know what to tell these devices; it does not contain any HVAC system control algorithms. Telling the thermostat is easier and lets the thermostat keep track of the HVAC system. The same control scenario applies to the lighting control and security systems. The necessary system-control software is contained in one easy-to-use node.
CEBus Reference Architecture and Media The CEBus standard establishes a set of Physical layer medium specifications to handle all the data communications needs of the home (audio, video, computer data, and so forth). It defines the use of the power-line wiring (PL), radio frequency (RF), and infrared (IR), and the installation and use of twisted-pair (TP) and coaxial (CX) cable. Figure 4.6 illustrates the reference architecture, or topology, for all media supported by CEBus as well as the interconnection of the media in the home and to outside service providers. Figure 4.6 illustrates all of the medium support components that might be used in a typical residential environment for CEBus message communications, as well as maximum utilization of internally and externally supplied wideband services. The standard is flexible enough, however, to allow the use of CEBus products in existing homes using the PL, RF, IR, and a majority of existing TP wiring with a minimum of additional components. Power-line-based products, for example, require a minimum of infrastructure support. There is no initial “network” to purchase and install. As products are purchased that utilize more of the capability of the media, additional infrastructure support components can be added incrementally. All media support components are collectively known as Node 0. The term Node 0 refers to all the physical components necessary to support the various medium networks. Node 0 consists of all Routers, Brouters, Data Bridges, and the TP, CX, and PL support hardware necessary for a given installation. The TP network requires a power supply and a distribution/termination device. The CX network requires a distribution device containing block conversion, amplification, and control-channel regeneration functions.
CEBus Basics
Figure 4.6 Brouters.
43
Reference media topology for CEBus networks. Media are interconnected by Routers and
Routers connect CEBus messages between two of the wired media (PL, TP, CX). Brouters connect CEBus messages between RF or IR and a wired media. Data Bridges connect any audio, video, or other wideband signals between media. The TP network architecture is based on TIA-570 (Residential and Light Commercial Premise Wiring standard). Branch runs of four-pair jacketed cable originate at the distribution device and run to each room where they connect to one or more outlets. Two of the pairs are used for external services, two are reserved for CEBus communications.
44
Chapter 4 The CX network consists of a pair of RG-6 cables that originate at the distribution device and run to each room where they split to one to four dual outlets. One cable handles delivery of external services (such as cable TV), the other cable is for distribution of in-home-generated control and data. Network Interface Units (NIU), typically supplied by an external service provider, provide the interface between the electrical characteristics of the external network and the electrical characteristics of the CEBus network. A NIU may interface any external network medium (coax, twisted-pair, RF) to any CEBus medium.
Channels The CEBus standard defines two types of communication channels available on each CEBus medium (Figure 4.7): a required control channel for device message communication, and a set of optional data channels for distribution of audio, video, or any wideband signals. The control channel is used on every medium to transmit and receive CAL messages. The control channel uses a frequency spectrum on each medium that is always available and completely defined by a fixed frequency allocation, amplitude, and encoding method. The control channel is required by all CEBus-compliant products to send and receive messages between nodes. Data channels are a reserved frequency space available on some media that may be used by CEBus devices equipped to send and/or receive analog or digital data. The data may be any information (music, computer
Figure 4.7 Each CEBus media is capable of supporting a Control Channel and one or more Data Channels.
45 files, compressed video, voice) as long as it is confined to the frequency and amplitude specified for the medium used. Data channels are currently available on TP and CX, although the standard allows data channels on all media. A VCR that sends its video output to an upstairs TV over the coaxial medium is a typical example of data channel use. The VCR and TV use the control channel—exchanging resource allocation messages—to establish the connection, and the data channels are used to send the video, freeing the control channel for other tasks while the data transfer continues on the data channels. Figure 4.8 illustrates the allocation of the frequency space on one of the two CX coaxial cables. The control channel is assigned the frequency space between 4.5 and 5.5 MHz. This frequency space is reserved for devices attached to CX for sending and receiving messages. The figure also shows the frequency allocation of the predefined data channels. The frequency space from 54 to 150 MHz is used for transmission of data on one or more 1.5 MHz channels. These channels are block converted in Node 0 to the 324 to 420 MHz range for reception by any CX node. The use of data channels is always optional. Access to the data channels is independent from access to the control channel. A product that uses data channels will have a separate transceiver (potentially frequency agile) to send and receive digital or analog data (Figure 4.9). There are two major differences between the control and the data channels. 1. While CEBus messages on the control channel are sent and received in packets that are completely defined by the CEBus protocol, the format and content of the data channels are open. A manufacturer can use data channels to send any data that can be transmitted in the frequency allocations and amplitude available for the channel or channels used.
Figure 4.8 Example of data channel use on CX.
46
Chapter 4
Figure 4.9 Each CEBus node must have access to the control channel. It may also access one or more data channels. The transceiver electronics for each channel may share the same coupling components and connector.
2. As described in the section on the CEBus communications model, the control channel is used for connectionless service only. Devices wait until the control channel is not being used, transmit a message, and relinquish control of the channel. This service is required because there is only one control channel shared by all devices. Each data channel, however, is used for connected service. Devices negotiate for the use of one or more data channels (using messages on the control channel) depending on the bandwidth required for the data to be transmitted. If no other node is using the requested channel(s), the requesting device can use the channel(s) as long as necessary to transmit the data. To transmit a computer data file, the connection might last for several seconds. In the example of the VCR transmitting to the upstairs TV, the channel might be in use for several hours. There are usually multiple data channels available on each medium so that several devices (64 in the case of CX) can have access simultaneously. Additional (non-CEBus) frequency space may be available on each medium for use by outside service providers (cable companies, telephone companies, and the like) who share the same medium. This allows products to have access to outside services as well as CEBus control and data channels on the same medium. For example, products such as set-top boxes can access cable company-supplied program material and control messages (pay-per-view video, utility company rates, database access), and CEBus data and control channels all on the same coax cable pair. The frequency allocation of each CEBus medium is described in Chapter 5.
47
CEBus Basics
Packets and Messages Information is transmitted over the control channel in packets of data at about 10,000 bits per second (bps) (regardless of the medium used). Packets contain the necessary “housekeeping” information, such as the address of the originator and destination node, as well as the message (the CAL commands directed to the destination node). A simple analogy can be made between the information contained in a CEBus packet and the information in a typical letter (see Figure 4.10). The message contains the packet “payload” as a CAL message or reply that a node wishes to send. The message is typically 4 to 10 bytes—only about one-fourth to one-half of the packet length. The addresses and service bytes make up the remainder of the packet. For a letter (message) to reach its intended receiver successfully, the letter is sent in an envelope (packet), and the envelope is addressed to a receiver (the TO address). To inform the receiver of the address of the sender (or to allow the letter to be successfully returned if it could not be delivered), the return address (the FROM address) is included on the envelope. Each CEBus product has its own unique address, acquired
Message
C ER TI FI ED
A
IR
M
A
IL
PACKET
CEBus Packet preData Link amble services
Figure 4.10
TO Address
FROM address
Network services
Application services
CAL message
FCS
CEBus packet structure illustrating the analogy of typical letter parts to packet fields.
48
Chapter 4 when the product is installed in the home. The address has two parts: a house address (that all products in one house or apartment share) and a device or node address that is unique to the product. When sending letters, the envelope can indicate one or more post office services, such as certified mail, next day delivery, or return receipt requested. Packets contain similar information. The Data Link services (handled by the Data Link layer) determine network access priority, and, thus, delivery priority, as well as a “return receipt requested” acknowledged service. The Network services (handled by the Network layer) determine packet routing through the network. The Application services (handled by the Application layer) determine whether a reply is requested from the receiver and message security. Message authentication can be requested in the Application services to prevent unauthorized users from accessing or changing information in some products. For example, the electric rate information stored in a CEBus electric meter can be read and changed by the electric utility because it has the correct authentication keys, but the information cannot be changed by nonutility devices that do not have the keys. The Preamble and Frame Check Sequence (FCS) shown at the front and end of the packet in Figure 4.10 are fields used by the Data Link layer protocol. The packet preamble, the first byte of the packet, is used for transmission collision detection. The FCS is used for received bit error detection.
Symbol Encoding When a CEBus device sends a packet, the data in the packet is converted from internal binary form to physical medium symbols. CEBus uses a set of four medium symbols, rather than the more common binary symbols used internally in computers. 1: binary one 0: binary zero EOF: End-of-Field—used to separate packet fields EOP: End-of-Packet—used to identify the end of a transmitted packet
CEBus Basics
49 Using four symbols instead of the usual two makes transmission and reception of packets easier. It allows an inexpensive and easy data compression technique, which is described in Chapter 6. All CEBus nodes encode symbols by generating one of two physical medium states. The two states are defined as the SUPERIOR state and the INFERIOR state. These terms generically define two electrical conditions of the medium that are easily detected by a receiving node. The state names imply that the SUPERIOR state can always override or be detected over the INFERIOR state. The idle state of the medium—the state when no packets are being transmitted—is always the INFERIOR state. Each CEBus medium uses different electrical conditions, appropriate to the medium, to represent the two states. Typical representations of the SUPERIOR and INFERIOR state on each medium are shown in Figure 4.11. The four symbols are encoded on each medium by using the time that the INFERIOR or SUPERIOR state remains on the media, not whether the INFERIOR or SUPERIOR state is used. The time is measured from the transition between states. The 1 symbol is represented by the shortest interval of either the SUPERIOR or INFERIOR state (100 s); the 0 is twice the interval of the 1; the EOF is three intervals; and the
Figure 4.11 Typical symbol encoding showing the four symbols and symbol times. The transition time between states determines the symbol.
50
Chapter 4 EOP is four intervals. Note that any symbol can be represented by either a SUPERIOR or INFERIOR state. The end of one symbol and the start of the next occurs at the transition from one state to another. Therefore, states alternate between SUPERIOR and INFERIOR for each new transmitted symbol in a packet. Because the idle state of the medium is always the INFERIOR state, the first symbol transmitted in a packet is always encoded with the SUPERIOR state. The packet can end in either state. The symbol time for the shortest symbol (1) is defined as the Unit Symbol Time (UST) and represents the minimum SUPERIOR or INFERIOR period. The UST is the basic unit of measure for timing in the protocol software. The packet data rate is the same for all CEBus media and is stated as 10,000 “one-bits” per second, because a packet containing all “1” symbols would transmit all symbols at 100 s, or 10,000 bps. In practice, because each packet contains a mix of the four symbols, the actual data rate varies with each packet, averaging about 8,500 bps. Compression techniques are used in the protocol to reduce the use of zeros where possible. The signaling technology used on each medium is tailored for the lowest cost implementation while providing the highest reliability. PL transceivers use a novel 100- to 400-kHz spread spectrum carrier technology developed by the Intellon Corporation. TP transceivers use a simple 10-kHz, 250-mV carrier; CX transceivers use an equally simple 4.5- to 5.5MHz carrier; and IR uses a 100-kHz, 850- to 1000-nM carrier. RF uses a digitally synthesized spread spectrum carrier centered at 915 MHz.
Network Attributes The symbol-encoding technique used in CEBus allows a uniform packet data rate and encoding on all media in the home. All nodes, regardless of the medium used, transmit packets using the same data rate, the same media states (SUPERIOR/INFERIOR), the same protocol (CSMA/CDCR, which are described in Chapter 5), and the same packet format. This allows packets transmitted on one medium to be routed to another medium with a minimum of conversion. The only difference is the electrical representation of the SUPERIOR and INFERIOR states in each medium. A product that uses the power line can be adapted to use twisted-pair by changing only the Physical layer transceiver electronics. All other parts of the interface and node software remain the same. This makes the job of Routers and Brouters much easier because they only need to convert media states.
51
CEBus Basics
CAL: What CEBus Products Say to Each Other The message portion of each packet contains the CAL command. CAL provides a common language interface so that products know how to communicate with other products without knowing how each specific product operates, who built it, or what features it has. CAL is responsible for implementing application-level interoperability. To achieve true interoperability on a large scale—to get products to work together in the home—there must be some predefined model of how products operate and a common set of commands to perform the operations. A TV built by Sony and a TV built by RCA should operate, from a CEBus standpoint, in the same way. A PC or a toaster needs to know how to change the channel on any CEBus-compliant TV regardless of manufacturer, and without having to consult with the manufacturer. This goal has been achieved by a set of predefined (but extensible) models for all consumer device functions in the home.
CAL View of Products The design of CAL is based on the assumption that all electrical appliances and products in the home have a hierarchical structure of common parts or functions, and the basic operation of the common functions is the same from product to product. CAL treats each product as a collection of one or more of these common parts called Contexts. A CEBus TV, for example, appears as a collection of Contexts at a network address as in Figure 4.12. A typical TV might consist of a video display Context, an audio amplifier Context, a tuner Context, a clock Context, a user interface Context, and so on, depending on the features of the model. CAL defines more than 50 different Contexts for everything from lighting, security, heating/air conditioning, to washing and drying. Each Context, regardless of what product it is in, operates the same way. The audio amplifier in the TV, in the stereo receiver, in the speaker phone, and in the intercom all work alike and “look” alike to the network. Each Context consists of one or more objects. An object is a software model of a well-defined control or sensing task. Objects model the way Context functions are normally performed manually. The volume, bass, and treble analog control objects and the mute binary switch object rep-
52
Chapter 4
Figure 4.12 Each CEBus node consists of one or more Contexts. Each Context is made up of the objects necessary to control available product functions.
Figure 4.13 Sample object table for an analog control object (object class 08). The object operation is defined by its nine variables.
resent controls typically found in audio amplifiers. CAL uses 26 predefined objects to model all control functions required for all known consumer/residential products. Objects, in turn, are defined by a set of instance variables (IVs). IVs are like variables in any software program, having a size and a data type. All network operations on Contexts are performed by reading and writing object IVs. The IVs that define each object are listed in the object tables in the CAL specification. Figure 4.13 is a representation of a typical object table.
Chapter Five In order for products to be successfully installed in the home, the specifications of the media used to make CEBus networks must be completely defined. Medium specifications allow manufacturers to make devices that they know can be installed in any home if the required medium has been installed correctly. For example, to use the power line to communicate, a manufacturer must at least know its electrical characteristics, the carrier signaling, data rate, and so on. On media such as TP and CX, a manufacturer must also know such things as the type of connector and cable to use. All aspects of physical interoperability must be defined. This chapter discusses the physical and electrical requirements of each of the media usable by CEBus: power line (PL), coaxial cable (CX), twisted-pair (TP), and radio frequency (RF). The physical media (PL, CX, and TP) are referred to as wired media and RF as the nonwired media. This chapter also discusses the design of the PL physical layer (PHY) in detail and the basic design of the TP, CX, and RF physical layers.
The CEBus Network Topology A network topology defines how nodes are connected to each other over the network medium. The topology defines how the medium or media are interconnected, the path from node to node over the medium, and routing of messages over the medium. A network (singular) implies a single uniform transmission path interconnecting all CEBus devices in the home. The job of making plugand-play products means making a network in the home easy to use, but creating that network is difficult due to the multiplicity of wiring, and the size and types of homes.
Architecture Assumptions Creating a usable network out of the power-line wiring, telephone wiring, coaxial cable, RF, and the like, requires a clear specification of how the media must be used, connected to, and interconnected. To simplify the task, the CEBus committee made some basic assumptions about the specified media, the minimum media requirements, and media interconnection. The first assumption was the basic medium reference architecture design described in Chapter 4 and shown here in Figure 5.1. This
The Media and Physical Layers
55
architecture defines the supported media and how the media are connected for the supported communications channels. The second assumption, which can be seen in Figure 5.1, is that the medium architecture forms a tree topology. A tree topology means that there is only one path from any node on the network to any other node. Like the leaves on a tree, there is only one path to get from any leaf to any other leaf. A tree topology also means that there is only one route from any medium to any other medium. This model allows all nodes to treat the several media that make up the network as though they were one medium and removes the burden of message routing from the nodes. The third assumption is that the tree is formed from the individual media by a set of Routers and Brouters. They handle the job of message routing and medium interconnection to ensure that a tree network is maintained.
Node 0 The term Node 0 (spoken “node zero”) refers to all the physical components necessary to support the various medium networks (see Figure 5.1).
Figure 5.1 CEBus reference architecture.
56
Chapter Five Node 0 collectively consists of all Routers, Brouters, Data Bridges, plus the TP, CX, and PL support hardware. The TP network requires a power supply and a distribution/termination device. The CX network requires a distribution device containing block conversion, amplification, and control-channel regeneration functions. The term Node 0 originated in the mid-1980s when some members of the CEBus committee thought that all support hardware for all networks (Routers, distribution devices, and so on) would be built into a single piece of hardware, purchased by the homeowner, and plugged into the power line, a TP outlet, and a CX outlet. This hardware would be the first CEBus component installed in the home, and would, therefore, be called Node 0. The concept that all necessary support hardware would be contained in a single device has long been abandoned, but the terminology stuck.1 Now any component built for network support is called a Node 0 device. There is a separate section in EIA-600 devoted to the various hardware interface requirements of Node 0.
Router and Brouter Requirements Routers and Brouters comprise one of the components of Node 0. They are the devices that “glue” the individual medium networks together to form one logical network. Routers
A Router has two jobs:
To connect the control channel of two wired media To maintain a tree topology A Router is a device that connects the control channel of one wired medium to the control channel of another wired medium. A Router may be connected between PL and CX, or PL and TP, or TP and CX. The job of a Router is to ensure that packets originating on one of its connected medium are retransmitted on the other connected medium. Its primary function is to make sure that the control channel of all the wired media are connected together so that nodes do not have to know what medium other nodes use. A packet transmitted on PL will wind up on the medium used by the destination node. 1
This is not to imply that a single Node 0 device cannot be built. In fact, one of the first Node 0 devices on the market, built by Grayfox Systems, contains all Node 0 support hardware for all media (including Router) in one box.
The Media and Physical Layers
57
Routers build an internal address directory of what node addresses are on the side of the network that they route to. This allows a more efficient packet-routing technique. Packets are only routed to another medium if the destination address is on that “side” of the network (that is, if the node is on one of the media that can be reached through the Router). There may be more than one Router installed between two media. This occurs if a consumer installs more than one CEBus-compliant device in the home that contains a Router. For example, a television may contain a Router that connects between the PL and CX media (because a CEBus-compliant TV connects to both). A purchased CEBus-compliant VCR—perhaps from a different manufacturer—may also contain a PL to CX Router because it connects to both media as well (see Figure 5.2). This violates the tree topology because a packet that originates on PL will be routed to CX by both Routers—the one in the TV and the one in the VCR. To prevent this condition, one Router must disconnect or stop routing. To maintain a tree topology, regardless of the type, location, and number of Routers installed between the wired medium networks, Routers have their own Router protocol. Routers exchange messages between themselves to determine which Routers should remain on-line and which must disconnect. The technique is best described by example. Assume, as shown in Figure 5.3, that a Router exists between PL and TP, and between PL and CX. Packets that originate on any of the wired media will be routed to all wired media. Now assume that another device (Figure 5.4) is added to the network that contains a CX to TP Router (perhaps a DSS receiver). This Router destroys the tree topology. Packets that originate on CX will be routed directly to TP by the CX-TP Router, and indirectly to TP by first being routed to PL by the PL-CX Router, and then to TP by the PL-TP Router.
Figure 5.2 Multiple Routers between two media may exist because products that connect between the two media may have internal Routers.
58
Chapter Five
Figure 5.3 Standard Router configuration between the three wired media.
This generates two copies of the same packet on TP. The problem is avoided by having one of the Routers stop routing. This is accomplished by communication between Routers. Every few seconds, each connected Router transmits what is called a HELLO packet on both of its attached media simultaneously. A HELLO packet is addressed only to Routers and contains information for Routers to use for configuration. Assume, in our example, that the PL-CX Router transmits a HELLO packet first (Figure 5.5). The packet is picked up by the PL-TP Router from PL, and by the CX-TP Router from CX. By chance, the PL-TP Router routes the message to TP before the CX-TP Router. The CX-TP Router picks up the message from TP. When the Router detects the same packet (that originated from the same Router) on both media, it determines it is forming a loop, and disconnects (that is, it stops routing). The CX-TP Router continues to receive packets from both media, but it does not forward packets. As long as the loop condition continues, it remains off-line. If another Router is disconnected (for example, the PL-TP Router), it will go back on-line again and begin routing. Brouters Brouter is an abbreviation of Bridging Router. Brouters are like Routers except that they route packets between nonwired and the wired media; that is, between RF and one of the wired media (PL, CX, or TP). An RF Brouter can be located anywhere in the home that allows reliable reception and transmission of RF throughout the house (like a portable phone). The range of an RF Brouter is typically 100 feet. This means that one RF Brouter is usually sufficient for a typical home, but more than one may be installed. The need to maintain a tree topology is also true of Brouters, but the technique used to prevent multiple packets is different. More than one Brouter may receive the same packet.
The Media and Physical Layers
59
Figure 5.4 Router configuration after CX-TP Router is added.
Figure 5.5 Use of the Router protocol to resolve multiple Router conflicts.
This results in more than one packet on the wired medium when only one was transmitted. The additional duplicate packets must be eliminated. Brouters cannot use the same technique for self-detachment that Routers use because there is no guaranteed transmission path on the nonwired side of Brouters. Because of this problem, duplicate RF packets must be eliminated using detection techniques in the CEBus node protocol. The technique is described in detail in the Network Layer Protocol section in Chapter 6. Data Bridges A Data Channel Bridge is like a Router for the data channels. Currently, only the wired media support data channels. If a device originates a data channel transmission on one media, it can be put on another wired media by a Data Channel Bridge. The Bridge receives one or more data channels on one medium and retransmits the information on another data channel on another medium. The Bridge changes the data channel output frequency to correspond to a valid channel on the output medium, and it can optionally change the modulation technique. Data Channel Bridges can operate only one way, receiving on one medium and transmitting on another, or they can be bi-directional, simultaneously translating between two media. A Data Channel Bridge must adhere to the same channel access protocol as any node; therefore, it must use the control channel on the medium
60
Chapter Five it transmits on to determine whether the desired data channel is available, or if it is being used by another device.
Medium, System, and Global Networks The interconnection of the various media in the home results in the formation of three different sub- and supertopologies as a result of how homes are wired: the medium network, the system network, and the global network. A medium network (Figure 5.6) consists of all nodes connected to one physical medium, such as the PL or TP medium. The size of the network is determined by the physical size of the medium. In the case of the TP and CX medium, the medium network is contained within one house or apartment. The PL medium network, however, extends to multiple houses and apartments because the physical wiring extends beyond the walls of the home. The system network (Figure 5.7) consists of all nodes on the network that share a common system address. The system network is a logical
Figure 5.6 A medium network.
Figure 5.7 The system network contains all nodes with the same system address on all media.
The Media and Physical Layers
61
division with all the nodes connected by all the media, regardless of physical house location, to a particular home. All CEBus nodes have a unique address pair: a system address and a node address. The system address is the same for all nodes in a house or apartment, while each node address—in a given system address—is unique. The purpose of the system address is to logically isolate the nodes in one house from the nodes in another house, particularly on medium networks that span multiple houses (PL, RF). Messages addressed to a node in one system address cannot be received by nodes in another system address. The global network (Figure 5.8) consists of all nodes that can communicate or hear each others’ packets. The best examples occur on the PL and RF medium network. The PL medium networks in adjacent homes are interconnected, forming a global network. For example, the packets transmitted by PL nodes in my house can be heard by nodes on the PL network in my neighbor’s house. The same is true of RF. The RF transmissions in my house can be expected to be heard by RF nodes in my neighbor’s house. All the nodes that can hear each other form a global network for that medium.
Connection to the Outside World The connection from the CEBus medium architecture to a Wide Area Network (WAN) such as the Internet, is through one or more Network Interface Units (NIUs). WAN services include twisted-pair telephone service, cable service, ISDN, cable telephone service, high-speed Internet access, and the like. An NIU performs at least two functions: It terminates the electrical characteristics of the external medium and translates, if necessary, to the local electrical characteristics. For
Figure 5.8 The global network consists of all nodes that are able to communicate.
62
Chapter Five example, it may connect between an external fiber-optic network and the house power line. It translates external signaling techniques and message formats to CEBus packets on CEBus media (and possibly from CEBus to an external format as well). For example, it may receive RF high-speed messages from an external cable network and translate them to standard CEBus packets on the house TP network. An NIU may be strictly used for data channels, control channels, or both. It may be part of Node 0 or connect to a medium like any other node. As long as it provides the necessary interface and isolation function, there are no other specific requirements.
The PL Network Power-line wiring is the most common CEBus medium because it is always available. All CEBus products use electricity and most connect to the power line for their power; therefore, it is natural to use the power line as a communications medium. However, while the medium is always available, it is not the easiest to use. The power line is not intended for any purpose other than to transport 60-cycle, 120-volt, high-current power, and its design is not at all conducive to data communications. The CEBus PL technology was developed to overcome many of the disadvantages and hardships of using the power line for data communications, including noise, severe attenuation, and a medium network that spans many houses.
Power-Line Topology Power-line wiring in the home consists of a series of wiring branches (carrying 120 volts AC) from a central circuit breaker (Figure 5.9). Several outlets connect to each branch, enough to average less than 15 to 20 amps for typical appliances. The breaker box is connected to a “service entrance” cable consisting of three wires, called L1, L2, and Neutral. There is 120 volts between L1 and Neutral, and between L2 and Neutral. There is 240 volts between L1 and L2. All 120 volt branches in the home use L1 and N, or L2 and N. All 240 volt branches use L1 and L2. The three-wire service is connected to a local distribution transformer (located on a concrete pad
The Media and Physical Layers
63
or on a pole) that steps the high voltage power company feed down to 240 volts for distribution to neighborhood houses or an apartment building. As many as ten houses (or twenty apartments) may connect in parallel to the same distribution transformer. All power-line wiring from the distribution transformer, including all branches in all attached houses, comprise the PL medium network. A physical connection exists between the outlets in any house with the outlets in all other houses connected to the same distribution transformer. This connection provides a signal path for all CEBus devices connected to the PL medium network. Figure 5.10 shows how the network appears to each node. This schematic shows that, as far as the PL wiring from the distribution transformer is concerned, there are no houses. Each 120-volt CEBus PL device
Figure 5.9 Physical representation of a typical PL network from a distribution transformer. There are typically 5 to 10 houses on one transformer.
Figure 5.10
Electrical diagram of the physical PL network from the distribution transformer.
64
Chapter Five transmits packets using L1 and N, or L2 and N, depending on the pair it is plugged into. Every 240-volt CEBus PL device transmits packets on L1L2. The network is large, and the loads are constantly changing. CEBus devices are also constantly being connected and disconnected. This means that the signal attenuation of the wiring and noise induced by appliances, such as motors and switching power supplies, is constantly changing as well. Packets transmitted in one house (or apartment) may travel to all other houses on the PL medium network. To prevent device interference between homes, CEBus creates system networks in each house using the system address partition. The system address logically isolates the nodes in one house from the nodes in another house. The address configuration algorithm employed by CAL ensures that no two houses (or apartments) have the same system address.2
CEBus Signaling on the PL To overcome the problems inherent in the power line, CEBus uses a spread-spectrum signaling technology for the control channel. Spreadspectrum signaling works by spreading a transmitted carrier over a range of frequencies rather than using a single frequency. The CEBus PL carrier is spread over the range of 100 to 400 kHz during each bit in the packet. Unlike traditional spread-spectrum techniques that use frequency-hopping or direct-sequence spreading, the CEBus PL carrier sweeps
Figure 5.11
Power line spread-spectrum waveform for a SUPERIOR state 1 symbol.
2
Several types of power-line carrier-isolation devices are available to electrically isolate a house or apartment from its neighbors. These devices usually take the form of an inductive filter placed in series with the incoming electric service. They attenuate both incoming and outgoing packets.
65
The Media and Physical Layers
through a range of frequencies as it is transmitted. A typical spread-spectrum waveform, representing the CEBus “1” bit, is shown in Figure 5.11. The waveform is synthesized from a table of 360 digitized values given in the standard. The points were chosen to maximize in-band energy while keeping harmonic out-of-band content to a minimum. Notice that the waveform frequency starts at 200 kHz and sweeps to 400 kHz, jumps to 100 kHz, and then sweeps to 200 kHz. The phase transition from 400 to 100 kHz was kept within the body of the waveform to better control the abrupt transition. The complete 200–400/100–200 kHz frequency sweep (called a chirp) takes 25 cycles in 100 s. Bandpass of Chirp The odd shape of the spread-spectrum carrier waveform is due to several technical and FCC requirements, and results in the frequency spectrum shown in Figure 5.12. The energy of the chirp is concentrated in the band of frequencies between 100 and 400 kHz. The amplitude of any out-of-band energy above 400 kHz must be less than 1 mV to not only meet FCC conducted emission limits, but to ensure that packets on PL will not cause interference with inexpensive AM radios attached to the same wiring. The amplitude of any out-of-band energy below 100 kHz must be less than 5 mV. This level also meets FCC limits and prevents potential interference with services such as LORAN.3 By literally hand “tweaking” the waveform, the band edges are fine-tuned to achieve a high degree of out-of-band attenuation while allowing up to 7 volts peak within the band. Filtering is still required to and from a PL transceiver, but is minimized by the wave shape.
7.0 V
Figure 5.12 Frequency spectrum of the PL spread-spectrum waveform. PL carrier spectrum 5 mV
1 mV
100 kHz 3
400 kHz
LORAN operates at 100 kHz throughout the United States and provides air and marine radio navigation.
66
Chapter Five Encoding States The waveform in Figure 5.11 represents the SUPERIOR state. Because it lasts for 100 s, it is a SUPERIOR 1. The 0, EOF, and EOP symbols are formed by repeating the waveform every 100 s. The INFERIOR state is represented differently during different parts of the packets. During the Preamble (the first byte of the packet), the INFERIOR state is represented by the absence of a spread-spectrum carrier—the normal form of the CEBus INFERIOR state. During the information portion of the packet (everything except the Preamble), the INFERIOR state is represented by the inverse SUPERIOR state; that is, the SUPERIOR state chirp is inverted 180° as shown in Figure 5.13. The “normal” SUPERIOR state is called the SUPERIOR Ø1. The INFERIOR state is referred to as the SUPERIOR Ø2 state (the phase inversion of SUPERIOR Ø1). The INFERIOR state is represented by the SUPERIOR Ø2 because it is necessary to have the carrier on at all times during the information portion of the packet to keep the receiver “locked” onto (to correlate and track) each Unit Symbol Time (UST) in the packet and to still be able to use the INFERIOR/SUPERIOR distinction to represent symbols. This greatly enhances received signal reliability. The INFERIOR state is represented by the absence of a signal during the Preamble to allow the Data Link layer (DLL) access protocol to function properly. This protocol relies on the detection of another node’s SUPERIOR state
Figure 5.13 The SUPERIOR Ø1 waveform and the INFERIOR state version of the waveform, the SUPERIOR Ø2 waveform.
The Media and Physical Layers
67
Figure 5.14 Portion of a PL packet showing two symbols of the Preamble and two symbols of the rest of the packet.
during the INFERIOR state (the absence of a carrier) to detect a collision with another transmitting node. A spread spectrum receiver works by recognizing the pattern of the received signal. It compares, or correlates, the received signal pattern with an internal representation of the pattern. If enough of the received pattern matches, the signal is detected. After the received signal pattern is initially matched, the receiver “locks on” to the carrier and its detection job becomes easier, because each following symbol must occur at regular 100 s intervals. It may take several USTs of carrier for the receiver to match the incoming spread-spectrum waveform correctly, but once locked to the waveform, symbol detection is robust.
Packet Encoding Figure 5.14 shows part of a typical PL packet. A packet starts with a Preamble consisting of a pseudorandom pattern of eight 1 or 0 symbols followed (on PL and RF only) by a Preamble EOF symbol consisting of eight SUPERIOR 1 symbols. The first symbol of the Preamble always starts in the SUPERIOR state. The Preamble EOF is followed by the information portion of the packet. A small portion of the Preamble and the information portion of the packet are shown in Figure 5.14. Notice that during the Preamble, the SUPERIOR state is represented by the presence of a carrier (the SUPERIOR Ø1 state), and the INFERIOR state is the absence of a carrier. During the information portion of a packet, the SUPERIOR and INFERIOR states are represented by the SUPERIOR Ø1 state and the SUPERIOR Ø2 state, respectively. One of the two versions of the carrier is on at all times. The timing of the states during the Preamble is slightly different. This timing difference allows easier detection of the Preamble, especially during noisy conditions, and prevents
68
Chapter Five the receiver from mistaking the Preamble for the information portion of the message if a collision occurs during the Preamble. The advantage of the spread-spectrum signaling used by CEBus is that it can overcome the two worst PL signaling problems: attenuation of a band of frequencies by certain electrical loads, and noise generated by dimmers, motors, and the like. The CEBus spread-spectrum carrier can tolerate attenuation and noise over many frequencies as long as enough of the signal gets through to the receiver. Because spread-spectrum receivers work by recognizing the pattern of the waveform and because they are relatively insensitive to the amplitude, the signal can withstand attenuation and noise that destroys nearly half the waveform and still be recognized by the receiver. This makes CEBus PL signaling highly reliable.
Physical Layer Implementation The PL physical layer is responsible for generating and detecting the presence of INFERIOR (both types) and SUPERIOR states on the PL medium. Figure 5.15 illustrates the typical components of the power line physical layer. The CELinx IC is a CEBus spread-spectrum symbol generator/detector. Symbol data is passed from the Data Link layer to the IC (1, 0, EOF, EOP). The IC generates the necessary spread-spectrum waveform that is bandpass filtered, amplified, and coupled to the AC line. The bandpass filter provides additional out-of-band attenuation. The coupling network consists of a toroid impedance-matching transformer and a 60-Hz blocking capacitor. Coupling is between Neutral and L1 or L2. Protection should also be provided for high-voltage AC transients coupled from the power line.
Figure 5.15 PL physical layer components for a typical power-line interface.
The Media and Physical Layers
69
The output network (amplifier, filter, coupling components), needs to provide an output signal between 100 and 400 kHz at a signal level on the power line of between 2.5 volts and 7.0 volts peak-peak into an impedance of 10 to 2 k. Power-line impedances vary greatly over this frequency range. The localized, lumped impedance of the power-line wiring in a home over the 100 to 400 kHz frequency range will vary from a low of 0.8 to 20 or more depending on the appliances connected to the network. Most of the attenuation experienced on the PL comes from attached devices, but because the power-line wiring has a typical impedance in the CEBus frequency range of about 10 per 100 feet, the wiring impedance tends to isolate transceivers from severe loads if they are far enough away. Reception of the spread-spectrum carrier is through the same coupling network as the transmitter and a receive bandpass filter. The bandpass filter reduces out-of-band received noise and prevents front-end overload. The receiver must be capable of detecting symbols correctly with a received signal amplitude of 0.5 mV to 7.0 volts while in the presence of impulse and continuous noise. This represents about a 65-dB received signal dynamic range. Figure 5.16 is a block diagram of a typical PL spread-spectrum IC. The received signal is amplified, A/D converted, and fed to the heart of the chip, the matched transversal filter. The filter provides correlation of the received signal with an internal template of the SUPERIOR Ø1 and SUPERIOR Ø2 waveform. The magnitude of the correlation is directly related to the quality of the received chirp. The state of the correlation (SUPERIOR Ø1 or Ø2) is determined by the phase of the chirp. Once the filter has begun to track the incoming data, it will maintain tracking with only marginal signals for over 1 ms before indicating a
Figure 5.16 Block diagram of typical PL transceiver IC. This example is based on the CELinx IC from Intellon Corp.
70
Chapter Five loss. The filter outputs an indication of a match with either waveform. The digital logic uses symbol-detection indication timing from the filter to compute received symbols and pass them to the attached Data Link layer. Transmitted symbols are fed to the output waveform generator. The waveform generator consists of three parts: a ROMed wavetable, a D/A converter, and an output amplifier. The 360-point wavetable contains the binary image of the output chirp. An address generator clocks through the complete table for each chirp transmitted. Either the “true” or inverted version of the wavetable data is output to a 6-bit D/A, depending on the SUPERIOR phase required. The IC also contains the CRC computation logic. As the packet is transmitted, the CRC logic computes a 16-bit CRC. When the EOP is received and transmitted by the chip, the 16-bit CRCs are appended to the packet. As a packet is being received, and the end of the Preamble is detected, the CRC logic does the same calculation on the received bits of the information part of the packet. When the EOP is received, the remaining 16 bits are internally stored and compared with the calculated CRC. The results of the comparison are passed to the Data Link as a “good packet” or “bad packet” indication.
PL Performance The reliability of the CEBus spread-spectrum control channel in a typical residential PL network is very good. Packets are typically delivered error free well over 98 percent on the first try. With the packet retry mechanisms built into the Data Link layer (described in Chapter 6), message delivery can approach 100 percent. However, no PL signaling technology is perfect and conditions can exist in a home that will severely interfere or completely block transmission. The problems—caused by other appliances that connect to the power line—fall into two categories: devices that generate power-line “noise,” and devices that absorb powerline signals. Devices that generate noise include broadband “blasters” such as wireless intercoms, baby monitors, and PL music distribution devices. The music distribution system is the worst. These devices transmit the output of stereo receivers or CD players to remote speakers plugged into the power line. The interference from these devices is worse when they are located near a CEBus PL receiver. Devices that absorb power-line signals are becoming more troublesome with the increasing popularity of PCs in the home and the accompanying proliferation of surge protectors. PCs limit the noise
The Media and Physical Layers
71
they couple to the power line by typically placing a large capacitor (0.1 f) across the power line at the power supply. This capacitor shorts noise from the PC as well as any other “noise” on the power line where it is connected, including CEBus spread-spectrum “noise.” A worse problem, however, is the proliferation of inexpensive surge protectors built into outlet strips and other power connection devices. To cut costs, these things simply place a large capacitor (and a MOV or two) across the power line and call themselves “protection.” These devices provide little protection, but potentially a lot of trouble. A CEBus node (or any device that uses a power-line carrier) plugged into one of these devices will usually not communicate. The only solution is to eliminate or inductively isolate them. A good surge protection device uses inductive isolation for attached loads. This prevents communications through the device but does not interfere with signals on the power line.
The TP Network The TP Physical Layer of the CEBus standard is based on the Telecommunication Industry Association (TIA) residential telephone wiring standard (ANSI/TIA/EIA-570A). TIA-570A is a residential telephone premise wiring standard that describes how new homes should be wired for high-quality telephone service. In the home, the standard specifies that a four-pair twisted and jacketed cable be run from a central location—or distribution point—to outlets in each room. Incoming telephone service is connected at the distribution device to each branch cable. CEBus builds on TIA-570 to include all the requirements necessary to transmit control and data channels on the same cable. The added CEBus requirements include the addition of a power supply to one of the pairs, and defining proper lengths and termination necessary to support the signal bandwidth used for control and data channels.
TP Cable and Wire Use The TP cable specified by the CEBus standard is the same as that specified in TIA/EIA-570A: four twisted, unshielded, jacketed pairs. This type of cable is referred to as UTP (unshielded twisted-pair) and is shown in Figure 5.17.
72
Chapter Five
Figure 5.17 TP cable uses four twisted-pairs labeled TP0, TP1, TP2, and TP3. Each pair uses a colored wire with a white stripe, and a white wire (which may have a small stripe of the same color).
Note that the TIA-570A specification specifies the use of Category 3 rated cable or better, while the CEBus specification is intended to use any twisted-pair cable rated Level 2 or better. TP cable ratings are described in ANSI/TIA/EIA-568 and TIA TSB-67. Each pair in the cable is color coded. The cable must use 22 or 24 AWG solid conductors with a maximum resistance of 29 per 1,000 feet. The cable must also meet the specifications listed in the following table. These specifications are easily met by 24-gauge Category 3 or better cable.
TP Cable Specifications Characteristic
Minimum
Maximum
DC resistance (per 1000 ft) 22 AWG:
18
24 AWG:
29 Ω
Mutual Capacitance
20 pf/ft
Attenuation (per 1000 ft) at 1 kHz:
0.5 dB
at 1 MHz:
7.8 dB
73
The Media and Physical Layers TP Cable Specifications (Continued) Characteristic
Minimum
Maximum
at 1 kHz:
500
700
at 1 MHz:
85
115
Characteristic Impedance
These specifications allow the four-pair twisted cable already installed in many homes to be used for control and data channel transmission. This minimum specification will give acceptable results with basic (Level 2) four-pair twisted cable with the length restrictions specified in the standard. Wire Color The pair coloring specified in the CEBus standard is based on the standard TIA-570A pair coloring and given in the following table.
TP Pair Coloring Specifications TIA Pair
CEBus Designation
Pair Color
Pair 4
TP0
Brown White/Brown
Pair 3
TP1
Green White/Green
Pair 2
TP2
Orange White/Orange
Pair 1
TP3
Blue White/Blue
Wire Pair Use Table 5.1 shows how each wire pair is used by the CEBus standard. Wire pairs are named TP0, TP1, TP2, and TP3. TP0 is used for the control channel and data channels. TP1, TP2, and TP3 are optionally used for data channels only. The use of data channels on TP is entirely optional and can be used only if the cable is dedicated to CEBus use. The selection of the wire pairs for CEBus is intended to allow easy coexistence with other services likely to be used on TP cable, including
74 TABLE 5.1 TP cable-pair usage showing control and data channel assignments to each pair.
Chapter Five 18V DC
TPO
Brown/White White
Control Channel
Data Ch. 4-32
TP1
Green/White White
Data Ch. 32-63
TP2
Orange/White White
Data Ch. 64-95
TP3
Blue/White White
Data Ch. 96 -128
voice, ASDL, Ethernet, and so on. It does not conflict with the newer HomePNA technology (that uses Pair 1—the blue pair). TP0 can also be used to distribute 18 volts DC to power low-voltage attached devices. The table shows the assignment of the control channel and data channels to each pair.
TP Control Channel The TP control channel is a 10-kHz square wave transmitted at baseband on TP0 in a reserved frequency band from 0 to 128 kHz. The remainder of TP0 and all of TP1 to 3 is reserved for data channels. The data channel frequency space on each pair is divided into 32 channels (each channel is 32 kHz wide). Figure 5.18 illustrates the control channel encoding. The control channel uses a low-voltage 10-kHz differential signal superimposed on the power supply voltage to encode the SUPERIOR and INFERIOR states. A SUPERIOR state is represented by the presence of either a positive or negative differential voltage relative to the average DC supply voltage present on the TP0. The encoding waveform can be thought of as the output of a 10kHz square-wave generator, gated on and off in multiples of 100 s to represent the symbols. Gating the square wave on for 100 µs (one-half cycle of the 10-kHz waveform) represents a SUPERIOR 1 symbol. Removing the waveform for 100 µs represents an INFERIOR 1. Notice that the SUPERIOR state waveform must be generated in such a way that there are an equal number, on average, of positive and negative half-cycles. This prevents TP control channel transmitters from inducing a DC bias. The voltage amplitude of the SUPERIOR state can vary between ±150 to 600 mV. The absence of a differential voltage (zero volts
The Media and Physical Layers
Figure 5.18
75
TP control channel encoding using a grated differential square wave.
with respect to the DC level) represents the INFERIOR state. The allowed output voltage variation for the control-channel waveform makes it relatively easy to meet a wide impedance variation by using a simple current drive output stage.
TP Physical Layer The TP physical layer requirements can be met in a number of ways. No specific TP transceiver ICs were available at the time this book was written. The TP physical layer can be implemented using existing ICs or discrete components. The basic transceiver requirements are shown in Figure 5.19. The control channel transmitter must be able to deliver a differential baseband signal in the range of 150 to 600 mV and be able to reliably receive the control-channel signal down to 25 mV. The input impedance must be 2.5 k or more while not transmitting. Out-of-channel signal amplitudes from the control channel waveform must be less than 2.5 mV above 128 kHz. Figure 5.20 shows a representative control channel transceiver in more detail. Coupling to and from TP0 is via a hybrid transformer with windings for the receiver section and transmitter section. The TP winding is D C blo cked by a capacitor. Power is extrac ted through a bucking choke to filter control and data channel AC components and to maintain a high input impedance at frequencies above about 2 kHz.
76
Chapter Five
Figure 5.19 Typical control channel electronics using inductive coupling to TP0. A simple blocking filter must be used if the device obtains power from TP0. The SE sublayer is the portion of the Physical layer that encodes and decodes symbols.
Figure 5.20 CX cable pairs. The Internal cable is bidirectional for all control and in-home data channels. The External cable is single directional (unless a reverse channel is used by the cable company).
Control Channel Data Channels 1-64
Internal
In-home-generated video
Cable TV Off-air (VHF/UHF/FM)
External
Optional in-home-generated video
The CX Network The CEBus coaxial cable (CX) network distributes audio, video, and wideband signal sources throughout the home. The network replaces the traditional single coax cable TV wiring and provides additional capability for distributing high data bandwidth source material. The network was designed by the CEBus Committee to distribute signals reliably up to 1 GHz to or from any coaxial outlet in the home. This bandwidth will handle any expansion of cable TV channel capacity for the foreseeable future. The CX network, like the TP network, originates at a central location in the home and provides branch cables to each room of the house. Unlike the TP network, CX is a true transmission—line network—each branch consists of a pair of coaxial cables, driven and terminated separately. One cable of the pair, the EXTERNAL cable, provides all source material (video, audio, data) from outside the home, such as cable televi-
77
The Media and Physical Layers
sion services or off-air broadcasts. The other cable, the INTERNAL cable, is used for all in-home–generated material such as video from VCRs, security cameras, data from computers, and audio from CD players. Figure 5.20 shows application assignment.
The Cable The CEBus coaxial cable specification is designed to be met by existing good quality RG-6 (or better) cable to handle signals up to 1 GHz with minimum attenuation and minimum radiation and leakage (into and out of the cable). The cable must meet the electrical and mechanical specifications in the following table. Coax Cable Specifications Characteristic
Minimum
Maximum
0.039”
0.042”
Center conductor Diameter:
36
Resistance/1000 ft: Dielectric O.D.
0.175”
0.185”
Shield % foil coverage: % braid coverage:
100% 59% 5
Resistance/1000 ft: Jacket O.D.
0.265”
0.281”
Impedance
72
78
Capacitance
17 pf/ft
Attenuation (dB/100 ft) at: 5 MHz:
0.80
1.2
100 MHz:
2.1
2.6
500 MHz:
5.0
6.1
800 MHz:
6.4
7.9
1000 MHz:
7.2
8.9
78
Chapter Five RG-6 coax should have at least two layers of foil and braid shielding; however, four layers (two foil and two braid) are recommended. Because two cables are used in each branch, it is preferable to install “siamesed” coax—two cables that are joined together like the two conductors of common lamp cord. The two cables must use different color PVC jackets (black and white) or be marked INTERNAL and EXTERNAL to distinguish between the internal and external cables.
CX Network Topology The CX network topology is shown in Figure 5.21. Cable-pair branches originate at a central distribution amplifier and block converter, and branch to a four-way cable splitter in each room. Within each room, up to four branches are run to dual cable outlets. In-home–generated data channel sources transmit on the INTERNAL cable. These signals are received at the amplifier/block converter, block converted to a higher frequency band, amplified, and then distributed back on all INTERNAL cable branches. External video sources (cable or off-air) are amplified and distributed on the EXTERNAL cable. An attached device, such as a television, can view outside services from the EXTERNAL cable, and in-home sources from the INTERNAL cable. The cabling topology must adhere to these rules: All unused outlet connectors and unused splitter connectors must be terminated in a 75 resistive termination. Each branch must have one to four CX wall connectors attached to the four-way splitter.
Off-air antenna
INTERNAL Cable EXTERNAL Cable
Cable Service
4 way Splitter
Amp./Block Conv. Distribution Device
Wall connector pair
4 way Splitter
Figure 5.21 CX cable topology. Any number of branches can be made from distribution device if proper amplification is provided. Each branch can also be “homerun,” instead of using a splitter (recommended).
150' MAX
The Media and Physical Layers
79
The maximum distance for any one branch from the Node 0 distribution device to the farthest wall connector must be no more than 150 ft. The signal input/output specifications must be met for the Node 0 distribution device to be capable of handling any number of cablepair branches. While the standard assumes that the outlets from any splitter are used in one room, the outlets may be placed anywhere as long as the total cable branch from the distribution device to the outlet does not exceed the cable branch limit of 150 ft. Because each branch contains two cables, the four-way splitter shown in Figure 5.21 really consists of two four-way splitters: one for the INTERNAL cable and one for the EXTERNAL cable. The signal attenuation inherent in the splitter is compensated for in the distribution electronics. The splitter can be installed anywhere as long as it is accessible for service. There is no specific location requirement for the placement of the four-way splitter in the branch. In fact, the four-way splitter can be inside the Node 0 distribution device. This produces a slightly different equivalent topology in which each branch cable run originates at the Node 0 distribution device and terminates at the wall connector. This is the way most coax distribution devices on the market operate. As long as the signal amplitude is the same from the distribution device as it is out of the splitter, the four-way splitter can be functionally integrated in the distribution device to allow “home runs” to each outlet.
Cable Connectors and Outlets Connection to the CX network is via a dual coax outlet as shown in Figure 5.22. The connectors are standard coax F-style screw-on feed-through jacks. The outlet must label the INTERNAL and EXTERNAL jack. Unused jacks must be terminated in 75 resistance, either by connecting to an external terminator, or by using a self-terminating jack. The standard recommends that the coax male connectors employ a push-on-and-lock mechanism to maintain connection with the female jack, and a self-crimping mechanism over an internal mandrel to maintain connection with the coax cable. The standard also recommends using polarized cable connectors that prevent a cable from being attached to the wrong outlet jack. The EXTERNAL cable connector is polarized with two tabs set 180° apart,
80 Figure 5.22 CX wall plate showing the two required connectors for INTERNAL and EXTERNAL cables. Distance shown between connectors is to allow attachment of a molded dual cable connector.
Chapter Five
INTERNAL
0.75" min.
EXTERNAL
while the INTERNAL cable connector is polarized with two tabs set 90° apart. Polarizing slots are shown in Figure 5.20.
Node 0 Distribution Device Figure 5.23 is a func tional blo ck diagram of the No de 0 amplifier/block converter/distribution device. The diagram only shows the general construction of the distribution device and is not meant to imply a specific implementation. Not all the items shown in the diagram are required. Control-channel packets are transmitted by CX nodes on the INTERNAL cable modulated at 5.5 MHz, and are received and combined at the INTERNAL splitter. A control channel regeneration device converts the packets to 4.5 MHz and amplifies them for distribution back on each INTERNAL cable branch. CX Node 0 Distribution Device Data channel signals transmitted from nodes on the INTERNAL cable are also received and combined at the INTERNAL splitter. They are passed through a 54–150-MHz bandpass filter prior to the block converter. The block converter converts the received 54–150 MHz band to a 450–546 MHz HI band (or to a 318–414 MHz LO band, selectable on the block converter). The blockconverted data channels are then amplified and placed back onto the INTERNAL cable.
The Media and Physical Layers
81
Figure 5.23 CX distribution device block diagram. The functions may be provided as separate components or combined in one box. Most of the functions are optional, including the return channel path for cable service.
An optional output selector can place the block-converted data channels onto the EXTERNAL cable if the frequency space is not in use by a cable service. The block diagram shows two sources of external video: an off-air antenna input and a cable input. One or the other can be used. Whichever source is selected, it is amplified and placed on the EXTERNAL cable. An optional low-frequency (5–50 MHz) return cable path is shown for use by cable service providers that have reverse channel capability.
Coax Control and Data Channels The frequency allocation for each cable is shown in Figure 5.24. The CX data channel resides at 4.5–5.5 MHz on the INTERNAL cable.
82
Chapter Five Attached devices transmit the control channel on 5.5 MHz, and the distribution device regenerates the signal back onto all attached INTERNAL cables at 4.5 MHz. The INTERNAL cable is used for distribution of all in-home–generated video. There are sixty-four 1.5 MHz data channels available from 54 MHz to 150 MHz. Standard NTSC video signals transmit on four contiguous data channels (6 MHz). Thus, 16 standard television channels can be transmitted simultaneously. The data channels are block converted to 450–546 MHz and amplified for redistribution back on the INTERNAL cable for reception by CX devices. The data channel frequencies were chosen to enable transmitted video channels to be viewed on standard cable television channels 70 through 85. Figure 5.24 shows two versions of EXTERNAL cable frequency use. One is for cable television, the other is for off-air (VHF and UHF) reception. The typical bandwidth used by cable companies is 54 to 450 MHz for cable channels 2 to 69, but many cable operators furnish additional channels and services up to 850 MHz. Off-air VHF and UHF frequencies are also shown. It is possible to place the block-converted data channels on the EXTERNAL cable for viewing by devices that only connect to the EXTERNAL
Figure 5.24
CX frequency allocations on the EXTERNAL and INTERNAL cable.
83
The Media and Physical Layers
cable. If cable service is being received and no cable signals are present above 450 MHz, the HI block-converted band can be placed on the EXTERNAL cable. If off-air service is being received, the LO block-converted band (318–414 MHz) can be placed on the EXTERNAL cable. These frequencies, however, are cable channel frequencies, and to view them, the receiver must tune to cable rather than off-air channels. CX Control Channel The CX control channel transmitter uses an amplitude shift-keyed 5.5 MHz carrier. The carrier output amplitude is nominally 100 mV peak to peak. The time the carrier is on or off determines the symbol. The presence of the carrier represents the SUPERIOR state, and the absence of a carrier represents the INFERIOR state. Figure 5.25 shows typical encoding for a CX control channel. The carrier is received by the control channel receiver at 4.5 MHz, having been block converted and amplified in the Node 0 distribution device.
CX Physical Layer The CX physical layer can be easily implemented using discrete components. The basic transceiver requirements are shown in Figure 5.26. The control channel transmitter must deliver a nominal 100 mV of 5.5 MHz ASK carrier. This can be easily implemented by gating a 5.5 MHz oscillator from the symbol data stream. The receiver must recognize the carrier down to 16 mV, and demodulate the AM back to a symbol data stream.
100 s "1"
200 s "0"
200 s "0"
200 s "0"
100 s 100 s 100 s "1" "1" "1"
5.5MHz 100 mV
SUPERIOR STATE
INFERIOR STATE
SUPERIOR STATE
INFERIOR STATE
SUPERIOR INFERIOR SUPERIOR STATE STATE STATE
Figure 5.25 CX control channel encoding. Nodes transmit an ASK 5.5 MHz carrier. Nodes receive the control channel at 4.5 MHz.
84
Chapter Five
Figure 5.26 CX Physical layer transceiver block diagram. Nodes transmit at 5.5 MHz and receive at 4.5 MHz.
CEBus RF CEBus RF communication uses the 902–928 MHz radio band. This band is just above the cellular phone band and is shared by other licensed and unlicensed users. This band was chosen because of the wide frequency space available for low-power unlicensed consumer devices, and because transceiver technology for this band is widely available due to the introduction of many 902–928 MHz consumer products. The CEBus RF medium is similar to PL in two ways: First, it is used by other services. The 902–928-MHz band is used by consumer unlicensed products such as portable phones, baby monitors, remote IR repeaters, and other low-cost consumer products. It is also used by some licensed applications such as vehicle locators and amateur radio. Second, it is not limited to a single apartment or house. Because CEBus RF devices have a range of about 100 ft, they can easily be received by neighboring houses and apartments. Therefore, all of the potential interference problems inherent in PL also exist on RF. While RF does not suffer like PL does from attenuating devices on the medium, it does have additional unique problems. RF signals at frequencies as high as 900 MHz are subject to relatively small metal obstructions, such as metal building framing, filing cabinets, refrigerators, and similar objects, that can cause signal reflections and blockage. Care must be taken during installation of RF devices to make sure that a usable signal path exists with other devices in the home.
CEBus RF Signaling The CEBus RF control channel also uses a spread-spectrum signaling technique. While the PL spread-spectrum carrier used an analog waveform, the RF carrier is digitally synthesized.
The Media and Physical Layers
85
The control channel is generated using a 4.3- to 6.2-MHz directsequence spreading function to modulate a 915-MHz carrier. This results in a double sideband output spectrum with sidebands centered at 5.25 MHz above and below the carrier frequency. The receiver can tune either or both sidebands. Like PL, the RF receivers are sensitive to the pattern of the received signal rather than the amplitude, and once the receiver “locks on” to a signal, it can still receive the packet in the presence of considerable interference, including other CEBus RF signals. The data rate and packet format is the same on RF as it is on CX, PL, and TP. While a frequency allocation is possible for a data channel, one has not yet been specified for CEBus RF. The CEBus RF specifications require that CEBus RF devices be able to communicate over a free space distance of 100 ft. In a home, the distance will be reduced depending on the materials in the home and device placement. While RF signals may be transmitted or received from a neighbor’s house, the different device system addresses will prevent message interference.
RF Control Channel Encoding Like PL, the RF control channel relies on the spread-spectrum carrier being always on during the information portion of the packet. This results in the need for two SUPERIOR states during the information portion of the packet, the SUPERIOR Ø1 and Ø2 to represent the INFERIOR state. The basic SUPERIOR Ø1 state is generated by a digital “spreading sequence” that modulates a 915 MHz carrier. Figure 5.27 illustrates that each SUPERIOR UST is made up of seven substates. A substate is generated from a series of 360 25.2-MHz bits that last for one-seventh of a UST and form a 4.3–6.2-MHz spreading sequence. Seven substates are combined (2,520 bits from seven spreading functions) to form one complete UST. There are two different, and opposite, spreading sequences. The top sequence shown in Figure 5.27 represent the bit order of the forwardspreading sequence. The 1 and 0 bit pattern of this sequence starts, as can be seen, from three 1s, then three 0s, then three 1s, and so on, forming a 4.2-MHz square wave. The bit sequence is dithered from three 1s and three 0s to a series of two 1s and two 0s (6.3 MHz) by the end of the sequence. In between, sequences of three 1s and 0s are mixed with two 1s and 0s, so that there is an even frequency distribution between 4.2 and 6.3 MHz. The bottom sequence in the figure is just the reverse; it
86
Chapter Five
Figure 5.27 RF UST encoding. Each UST consists of one of two combinations of a 360-chip sequence. One combination forms the SUPERIOR Ø1; the other combination forms the SUPERIOR Ø2.
spreads from 6.3 MHz to 4.2 MHz and is called the reverse-spreading sequence. The normal SUPERIOR state, the SUPERIOR Ø1, is formed by combining the spreading sequences in the order shown in Figure 5.25: forward, forward, forward, reverse, reverse, forward, reverse. The SUPERIOR Ø2 UST, used to represent the INFERIOR state during the information portion of the packet, is formed by combining the spreading sequences in just the opposite order. The reverse pattern makes it easy for the spread-spectrum receiver to differentiate between the two states. The spreading sequence that makes up each SUPERIOR state is repeated as many times as necessary to form each symbol (twice for zero, three times for an EOF, and four times for an EOP). During the Preamble, the INFERIOR state is represented by the absence of a spread-spectrum carrier. The absence of a carrier or signal is the normal form of the CEBus INFERIOR state. During the information portion of the packet, the INFERIOR state is represented by the reverse SUPERIOR sequence; that is, the SUPERIOR Ø2 spreading sequence in Figure 5.25. The INFERIOR state is represented as a SUPERIOR Ø2 state because of the necessity of having the carrier always on during the information portion of the packet so as to keep the receiver “locked”
The Media and Physical Layers
87
onto the packet while still using the INFERIOR/SUPERIOR distinction to represent symbols. This greatly enhances received signal reliability. The INFERIOR state is represented by the absence of a signal during the Preamble to allow the Data Link layer (DLL) access protocol to function properly. The protocol relies on the detection of a carrier during the INFERIOR state to detect a collision with another transmitting node. A spread-spectrum receiver works by recognizing the pattern of the received signal. It compares, or correlates, the received signal pattern with an internal representation of the pattern. If enough of the received pattern matches, the signal is detected. Once the received signal pattern is initially matched, the receiver locks on and its job becomes easier because each following symbol must occur at regular 100 s intervals. Figure 5.28 shows a sample of the packet waveform. During the preamble portion of the packet, the SUPERIOR state is represented by the presence of the SUPERIOR Ø1 carrier spreading (although slightly modified), and the INFERIOR state is represented by the absence of a carrier. During the information portion of the packet, the SUPERIOR state is represented by the SUPERIOR Ø1 carrier spreading and the INFERIOR state is represented by the SUPERIOR Ø2 carrier spreading. The timing of the spreading sequence during the preamble is slightly modified (the symbol time is 114 s, and a slight delay is placed between each substate). This timing difference enables easier detection of the Preamble, especially during noisy conditions, and prevents the receiver from mistaking the Preamble for the information portion of the message if a collision occurs during the Preamble.
RF Physical Layer The RF physical layer is responsible for generating and detecting the presence of INFERIOR (both types) and SUPERIOR states to and from the RF medium. Figure 5.29 illustrates the typical components of the RF physical layer. This diagram is based on the CELinx RF CEBus spreadspectrum IC made by the Intellon Corporation. The RF CELinx IC is a digital spreading-sequence symbol generator/detector. Symbol data is passed from the Data Link layer to the IC (1, 0, EOF, EOP). The IC generates the necessary digital spreading sequence for SUPERIOR Ø1 or SUPERIOR Ø2. The digital spreading sequence is bandpass filtered and mixed with the output of a 915-MHz local oscillator. The outputs of the mixer (both mixing products) are
88
Chapter Five
Figure 5.28 Portion of the RF packet showing two bits of the preamble and two bits of the information portion of the packet. During the Preamble, the formation of the SUPERIOR UST is altered to prevent false receiver synchronization.
Figure 5.29 Typical RF transceiver block diagram. Output of the spreadspectrum digital IC is converted to the RF frequencies by a 915MHz local oscillator.
amplified and coupled to an antenna. The RF output spectrum looks like Figure 5.30. The mixer generates two 2.1-MHz sidebands, one centered at 909.75 MHz, the other centered at 920.25 MHz. The radiated output power of the transmitter depends on the antenna design and other product physical characteristics. The minimum power should produce a signal strength of 58 mV/meter measured at 3 m. Maximum power cannot exceed the radiated power limits prescribed by the FCC for Part 15 operation. The receiver section amplifies the antenna signal through a bandpass front-end filter. The receiver can use either sideband, or it can switch between sidebands to avoid interference. The received signal is mixed
89
The Media and Physical Layers
Figure 5.30 Mixing the chip data stream with the local oscillator forms two sidebands that are 10.5 MHz apart and centered at 915 MHz.
2.1 MHz
909.75 MHz LSB
2.1 MHz
915.0 MHz carrier center frequency
920.25 MHz USB
with the 915-MHz local oscillator to directly recover the spreading sequence bitstream. This is amplified, limited, and fed to the RF CELinx IC. The IC performs state detection by correlating the received bit sequence with an internal model of the sequence; if a match occurs, it generates an indication to the DLL of the received symbol. The IC also contains CRC computation logic. As the packet is transmitted, the CRC logic computes a 16-bit CRC. When the EOP is received and transmitted by the chip, the 16 CRC bits are appended to the packet. As a packet is being received, and the end of the Preamble is detected, the CRC logic does the same calculation on the received bits of the information part of the packet. When the EOP is received, the remaining 16 bits are internally stored and compared with the calculated CRC. The results of the comparison are passed to the Data Link layer as a “good packet” or “bad packet” indication.
Chapter Six The CEBus protocol provides a dependable, two-way, flexible message delivery system for large volumes of traffic on each medium. The CEBus protocol defines the format of the transmitted packets (the order of transmitted fields), the packet delivery “services” (error detection, message priority, retransmission of lost messages, responses to messages, and so on), and the technique for accessing and using the control channel on each medium.
A Little Protocol Background CEBus inherited much of its original protocol design from Homenet. In the early 1980s, a newly formed group at General Electric, led by Jack Francis, developed Homenet—the first communication protocol specifically designed for the home. Homenet was used in GE’s HomeMinder product. It was the first home automation system available to the consumer that provided whole-house automation using low-cost two-way communications on the power line. Over years of review and refinement, many changes were made to the protocol to reflect demands for higher speeds, greater reliability, and security, and much of the Homenet design was lost. However, the Data Link layer still retains many of the original Homenet concepts.
CEBus Protocol Overview In the early 1980s, the International Standards Organization (ISO) adopted a model for open communications systems, which is known as the Open Systems Interconnect (OSI) reference model. This model was intended to be used in the definition of actual protocols. The protocol used by CEBus is described in EIA-600 using the OSI model. The OSI model defines the functions and services available in any communications protocol, and is used as a basis for protocol designs. The operation of most existing communications protocols (Ethernet, TCP/IP, Novell IPX/SPX, AppleTalk, Fishnet, and so on) can be described using the OSI model. Due to its wide use and acceptance, the CEBus Committee also chose this model to describe the CEBus protocol, and the EIA-600 sections on protocol are based on the OSI format and terminology.
93
Protocol
The model has several advantages. It takes all the complexity of communications software and divides the functions into seven predefined “layers.” For this reason, the model is often called the OSI seven-layer model, or the OSI seven-layer protocol stack. A diagram of the stack is shown in Figure 6.1. The model defines the seven protocol functions in a hierarchical way, each layer of the model relying on the “services” of the layers below it. Each layer has a specified set of responsibilities and, ideally, only communicates with the layer above and below. Starting at the Application layer, each layer below provides a more “primitive” protocol service for the layer above. The top layer, the Application layer, corresponds to the application using the protocol. The lowest layer, the Physical layer, corresponds to the lowest-level tasks, usually associated with the hardware necessary to transmit each bit of the data on the connected medium. The model is similar to the way software languages use subroutines. Each layer “calls” the layer below to provide a more primitive function. Each layer is assigned a general set of services: The Physical layer is responsible for reliably transmitting and receiving each bit, or symbol, on the attached medium. All issues ISO Open Systems Interconnection Model APPLICATION PRESENTATION
CEBus Model
APPLICATION TRANSPORT
SESSION TRANSPORT NETWORK
NETWORK
DATA LINK
DATA LINK
PHYSICAL
PHYSICAL
MEDIA
Network Layer Management
Figure 6.1 CEBus protocol model vs. traditional OSI seven-layer model.
94
Chapter Six dealing with mechanical and electrical implementation are determined at this layer, including signal levels, bit transmission timing, bit error detection, and maintaining proper physical and electrical characteristics on the medium. The Data Link layer provides reliable communications between nodes on the same medium. The Data Link layer defines the fundamental unit of data transfer, which is often referred to as a packet or frame. The packet is the concatenation of preamble, addresses, headers, message information, and error-control codes. The Data Link’s primary responsibility is proper access of the media, including collision avoidance and detection. It also performs packet error detection, packet transmission timing, address recognition, duplicate packet rejection, and packet transmission failure detection and retransmission. The Network layer provides reliable communication across multiple media, including networkwide communication functions such as network address management. The Network layer provides routing services to ensure a packet arrives at the correct destination node on the correct medium. The Transport layer provides end-to-end service between source and destination nodes on the network. This is performed by requiring the destination node to acknowledge successful message reception and retransmission of packets that are not acknowledged. The Transport layer also handles large message fragmentation and reassembly, and the creation and maintenance of network connections that are required by the Session layer. The Session layer manages communication sessions or connections. Sessions allow nodes to establish single or bidirectional logical connection until all communication is complete, and then relinquishes the connection. This service is typically used for connected service protocols such as time-sharing service access, telephone systems, and the like. The Presentation layer provides any necessary translation of application data into a form used for packet transmission. It is responsible for converting transmitted and received data to a form usable by the Application layer. The Presentation layer is typically used to convert file formats (graphics, bitmaps, and so on) and handle the conversion of a local format to a remote node format. This layer can also implement data compression/decompression to yield higher throughput on the network.
95
Protocol
The Application layer is the application using the communication services of the lower layers. This may be an operating system, a communication program, telemetry software, and the like. The OSI model is just that—a model—and no one protocol adheres to all services and layers of the model. Specific protocols use a subset—as appropriate to the communication services offered by the network—of the services of each layer. Specific implementations of protocols also take liberties where different services reside and how layers are implemented. The model is used as a guideline for specific implementations.
The ISO vs. CEBus Model Figure 6.1 also shows the CEBus protocol model in relation to the OSI model. CEBus implements a Physical layer, a Data Link layer, a Network layer, and an Application layer. In addition to the protocol functions defined by the OSI model, the CEBus standard also defines the physical characteristics of each of the allowed media. It also implements many of the functions of a Transport layer, but instead of establishing a separate Transport layer, the needed functions are included in the Application layer and the Network layer. CEBus also defines Network layer management functions of each layer and the interaction between layers. Network layer management includes the housekeeping functions required between layers such as power-on states, error resets, and resource management. Because CEBus is a connectionless service protocol, no Session layer functions are used. The Presentation layer is not necessary because there is no requirement for conversion of data to or from a format used by the Application (the Application in CEBus is the CAL language interpreter).
The Peer-to-Peer Layer Model The concept of peer-to-peer node communications (introduced in Chapter 4) is applicable to each protocol layer. Each protocol layer communicates on a peer-to-peer basis with the corresponding layer of the node it is sending to or receiving from. The concept is illustrated in Figure 6.2. The task of the protocol, including the CAL interpreter, is to make the application (the hardware) of the node behave as though it is connected, for a short time, to the hardware in another node. The protocol establishes this “virtual” connection by transporting the hardware function from one node to another. The CAL interpreter converts the
96
Chapter Six connection request into words (CAL commands), which are sent to the other node in the CAL message. The CAL interpreter in the originating node then communicates with the CAL interpreter in the destination node, which converts the words back into an action on the destination hardware. This may result in a reply message from the destination CAL interpreter back to the originating node CAL interpreter. The CAL interpreter in the originating node relies on the services of the rest of the protocol “stack” to reliably deliver the message to the CAL interpreter in the destination node. To deliver the message, the CAL interpreter passes the message to the Application layer for delivery. The Application layer software prepends an Application layer message to the CAL message to form an Application Protocol Data Unit (APDU). The APDU is sent to the Application layer in the destination node. The added APDU information informs the destination Application layer about requested services, such as whether the message is encoded and whether a message acknowledgment is requested. The added bytes are called the APDU Header and are intended for the destination Application layer to determine what Application layer services are requested. The Application layer, in turn, passes the APDU to the Network layer for transmission. The Network layer software prepends a Network layer message to the APDU to form the Network Protocol Data Unit (NPDU). The NPDU is sent to the Network layer in the destination node. The prepended information is called the NPDU Header and is used by the destination Network layer to determine what network wide services are requested. For example, the APDU may be too large to send in one packet (a single APDU is limited to 31 bytes). The Network layer can segment the APDU into two or more messages and inform the destination Network layer, in the NPDU Header, how many segments are being sent. The destination Network layer reassembles the segments prior to passing
Figure 6.2 Each layer of the protocol communicates directly with the same layer in the destination node.
application CAL APPLICATION NETWORK DATA LINK PHYSICAL
FUNCTION
application
CAL message
CAL
APDU NPDU DLPDU
message
APPLICATION
APDU
NETWORK
NPDU
DATA LINK
DLPDU
PACKET
PHYSICAL
97
Protocol
the APDU to the Application layer. The NPDU Header information is also used by network Routers and Brouters to determine how the packet is to be routed through the network. The Network layer, in turn, passes the NPDU to the Data Link layer for transmission. The Data Link layer software prepends a Data Link layer message to the NPDU to form the Data Link Protocol Data Unit (DLPDU). The DLPDU is sent to the Data Link layer (DLL) in the destination node. The prepended information is called the DLPDU Header. The DLPDU Header contains the destination node network address and the originating node address, as well as a request for one of several possible acknowledgments from the destination node. The destination node DLL determines whether the destination address matches its own address and returns any requested acknowledgment to the originating DLL to indicate the packet was successfully received. The Data Link layer must gain access to the time-shared medium using a CSMA/CDCR protocol (Carrier Sense, Multiple Access/with Collision Detection and Collision Resolution). Once access is obtained, the DLL passes the assembled DLPDU to the Physical layer serially, a symbol at a time, for transmission on the medium. The Physical layer converts the symbols to either a SUPERIOR or INFERIOR state for reception by the destination node Physical layer.
Transmission Failures The CAL message transmission from the originating node to the destination node may fail anywhere along the path from the originating CAL interpreter to the destination CAL interpreter. If a failure occurs in the originating node “down” the path from the application to transmission by the Physical layer, the requesting layers are informed of the error by the lower layer where the failure occurred. For example, if the Data Link layer was unable to transmit the message (if it was unable to gain control channel access after a certain period of time), it will inform the layer that requested the transmission (the Network layer). That layer will, in turn, inform the layer above, up to the application. Each layer may attempt to retry, or if the retry fails, give up. Eventually, the application must decide how to handle the error (try again, inform the user, or give up). If the failure occurs in the destination node, each destination layer is responsible for communicating back to the corresponding originating layer that it is unable to handle the message. For example, if the originating node
98
Chapter Six Application layer requested secure services from the destination node (by indicating that the originating CAL message is encrypted), and the destination node is not able to handle secure messages—encrypting is an optional service—then the destination node Application layer must send an APDU Header back to the originating Application layer. The returned message (an APDU reject message) will indicate that the message was rejected because the destination node could not handle secure messages. The returned packet contains only an APDU Header, no CAL message. The originating Application layer may then inform the device application that message transmission failed at the destination node.
Application Layer vs. the Application The distinction between references to the CEBus product application and the protocol Application layer can be confusing. Practically, the CEBus node application, as far as the protocol is concerned, is the CAL interpreter. It is the originator and receiver of messages. Formally, however, the CAL interpreter is considered an element of the protocol Application layer. The node application is the hardware and software that performs the application of the node, such as turning on or off a light or operating a television set. Formally, the device application is the user. The device application (user) calls on the services of the protocol, via the CAL interpreter, to connect to the application in another node. While most messages originate as the result of an application changing a context data structure (resulting in the CAL interpreter generating a message), the application can also generate a message directly and request message delivery from the Application layer (this is why the Application layer, in Figure 6.2, “touches” the device application).
Packet Format The CEBus packet structure (Figure 6.3) reflects the contribution of each protocol layer to the packet. The DLPDU, NPDU, and APDU are built by the Data Link layer, Network layer, and Application layer respectively. The remaining non-PDU parts of the packet are the Preamble and the Frame Check Sequence (FCS). The Preamble is a random 8-bit value prepended to the start of the packet by the Data Link layer. The Preamble is used during the medium access protocol to detect and resolve collisions between transmitting nodes. The FCS is a packet-level error-detection field appended by the Data Link layer (an 8-bit checksum) or the
99
Protocol
Physical layer (a 16-bit CRC) depending on the medium used by the node.1 Packets vary in size from about 50 bits (the smallest packet) to about 350 bits (the largest packet) depending on the size of the CAL message and the content of the PDU headers.
Layer Responsibilities The rest of this chapter describes the functions and services of each protocol layer. It is important for anyone using CEBus—whether you write protocol software, buy it, or use an IC containing it—to be familiar with the services that the protocol provides. This is because the services must be requested by the device application; they are not determined automatically. When sending a message to another node, the application is responsible for knowing where the message goes (the destination address of the receiving node or nodes), as well as how to get it there (the protocol services necessary for successful transmission). The following protocol layer sections explain the services provided by the layer well enough for you to know where and when to use the services of that layer.
Application Layer The CEBus Application layer is responsible for the interface with the node application. Figure 6.4 illustrates the Application layer in more
Figure 6.3 Representation of the packet format. Each portion of the packet is contributed by one of the three layers of the protocol. 1
An 8-bit checksum is used on TP, IR, and CX. A 16-bit CRC is used on RF and PL. FCS formation is covered in the Data Link Layer Section and the Physical Layer Section.
100
Chapter Six detail. The Application layer is made from two subparts: The CAL Interpreter Element and the Message Transfer Element. The CAL Interpreter receives messages, parses them, and updates the Context data structure accordingly. It also generates a message for transmission if a reporting condition in the Context data structure requires it. The Message Transfer Element (MT Element, or MTE) builds the APDU. It receives message transfer requests from either the CAL Interpreter or directly from the application, builds the APDU, and passes it to the Network layer. It receives APDUs from the Network layer, parses the APDU Header, and passes the message to either the CAL Interpreter or directly to the application, depending on the type of message. The specific responsibility of each application element is shown in Tables 6.1 and 6.2. The CAL Interpreter element tasks are given in Table 6.1. This table indicates the tasks performed when receiving or sending a message. The Message Transfer Element tasks are given in Table 6.2. The table indicates the tasks performed when receiving or sending an APDU. The MT Element receives requests to transmit messages from either the CAL Interpreter or directly from the application along with the Application and lower protocol layer service requests. It builds the APDU and passes it down to the Network layer along with service requests for the Network and other protocol layers. Upon APDU reception, the MT Element parses the APDU Header from the message, performs the service requested in the header, and passes the message to
Figure 6.4 Application layer structure. The Application layer contains the CAL Interpreter and the Message Transfer Element.
101
Protocol TABLE 6.1
ELEMENT
Sending Task
Receiving Task
CAL
Monitor reporting IVs
Parse messages
Generate report messages
Update context data structure
Generate response messages
Handle error conditions
CAL Element tasks
Generate error messages
Table 6.2 Message Transfer Element tasks.
ELEMENT
Sending Task
Receiving Task
MT
Build APDU
Parse APDU
Handle authentication response
Handle authentication requests
Handle acknowledged service timing
Handle acknowledged service requests
Handle APDU retransmission
either the CAL Interpreter or to the application depending on the type of message received, and which element originated the message in the sending node. The MT Element is responsible for two primary protocol services offered by CEBus: end-to-end acknowledged service and authentication.
The APDU Header The APDU Header is built by the originating MTE for use by the destination MTE. There are two forms of the header: A 1-byte Basic Service header used for nonsecure service requests, and a multibyte Extended Service header used for security authentication services. The format of the Basic Service header is shown in Figure 6.5. The format of the Extended Service header is shown in Figure 6.6.
Basic Service APDU The content of the 1-byte Basic Service APDU Header is illustrated in Figure 6.5. This is the most common form of the APDU and is used for all nonsecure messages.
102
Chapter Six
Figure 6.5 Basic Service APDU header. The first two bits (27, 26) are always set to 1 for this service. The remaining contents of the byte infer the type of message.
Figure 6.6 Extended Service adds authentication to the basic APDU services. The first two bits in the first byte are always 1,0. The authentication algorithm used determines the contents and number of the optional authentication data fields surrounding the CAL message.
The basic APDU consists of a 1-byte header followed by a 0- to 30-byte message. The header determines the Application layer services. The Mode bit (MSB) is always a 1. It indicates the message service is CEBus. This bit may be used in the future to indicate transport of other, non-CEBus information.
103
Protocol
The Type bit is 1 for 1-byte Basic Service APDU (0 for variable length Extended Service). The APDU type is a 3-bit field indicating the type of service requested of the originating and destination MT Elements. The services are explained in detail in the section on Basic MT Delivery Services. The 3-bit invoke_ID field is used with the APDU type bits as a message number tag to allow MT Elements to track outstanding “invoke” requests to other nodes. The invoke_ID is assigned by the originating MTE. Any response from a destination node contains the same ID that was used in the original request.
Extended Service APDU The content of the multibyte Extended Service variable length APDU Header is illustrated in Figure 6.6. Extended Service APDUs are only used for secure message transfer using a message authentication process with optional encryption. The first two bytes of the header are always present. The remaining bytes (3−n) contain the CAL message and a variable number of authentication data bytes, depending on the authentication algorithm used. The Mode and Type bits are used the same as in the Basic Service APDU. The Type bit is set to 0 to indicate Extended Service. The ENCryption bit is used to indicate that the included CAL message is encrypted. The APDU type is a 5-bit field indicating the type of authentication service requested of the originating and destination MT Elements. The services are the same as the Basic Service APDU with the addition of the first two types listed (Challenge_request and Authenticate_response). The second byte of the Header contains a 5-bit Authentication Algorithm ID field. This field indicates the type of authentication used by the originating node and allows implementation of 32 different algorithms. The invoke_ID field is the same 3-bit field used in the Basic Service APDU. The remaining variable number of bytes in the header are used for the CAL message and the message authentication data. The number and
104
Chapter Six location of bytes used for authentication data depends on the Authentication Algorithm used as indicated by the Algorithm ID. The use of Extended Service APDU and an explanation of authentication is given in the Security Section of this chapter. Basic MT Delivery Services The MT Element offers several delivery services to the CAL Interpreter or application. The services ensure reliable message delivery by requiring that the receiving node (or nodes) generates a response message to the sending node. The response serves two purposes. First, it indicates that the destination node received the message successfully, and second, it provides a mechanism to return result data back to the originating node. For example, if a message is sent to a thermostat asking for the current heating setting, the value of the heating setting is returned to the sender in the response message. There are four basic MTE services: implicit_invoke, explicit_invoke, conditional_invoke, and explicit_retry. The MTE Extended Services combine these with message authentication. Implicit_invoke is a simple one-way service—a message is transmitted but no response is requested. This service is typically used when a message is broadcast to a large number of nodes using the broadcast system address or a group address when a replay is not needed from the receiving nodes. Explicit_invoke, conditional_invoke, and explicit_retry services are variations on the same service; however, a response from the destination node is requested. Explicit_invoke service requires an end-to-end acknowledgment from the destination MTE. This service is used to ensure that the destination node receives the message and the result of the message is returned. End-to-end means that the service operates over the entire network regardless of the media connection of the communicating nodes. A result will always be returned even if the result is just an indication that the message was executed. This service is also used when a value is read from the destination node. Conditional_invoke service requests a response if, and only if, the transmitted message produces a positive result in the destination CAL interpreter. Conditional_invoke is typically used to find which of many nodes meet a certain criterion.
105
Protocol
Explicit_retry is the same as explicit_invoke with the addition of an automatic retry service performed in the MTE. When a reply to the APDU is not received within a fixed time interval (typically 1.5 seconds), the MTE retransmits the APDU a second time. NOTE: The use of explicit_retry service is optional and is not recommended because a receiving node may not support this service in its MTE. This service is easily implemented in the application code that originates the message. If a reply is not returned, the application simply retries the message. The remaining APDU types are returned as a result of using the above services. Result is the APDU type of a returned message containing a result generated by an Explicit or Conditional request. Reject is the APDU type returned when the MTE in the destination node encounters an error condition and cannot process the message. Receipt_Ack is the APDU type returned when using explicit_invoke service and the destination node is delayed in responding.
Basic Service Details The following sections describe the operation of explicit_invoke, conditional_invoke, and explicit_retry service in enough detail for you to understand the basic operation of each service and when it is used.
Explicit_invoke Service Explicit_invoke service is used anytime a message is sent to one or a small group of nodes and a response is desired from the destination node(s). The response indicates that the message was received and acted on. This service provides a high degree of message delivery reliability and is used whenever possible. This service must be used when a value is read from the destination node and a returned result is required. The returned message will have a Result APDU type with the same invoke_ID as the original explicit_invoke APDU, and a result code (along with any returned value) in the message portion of the APDU. The possible returned results are:
106
Chapter Six A result complete code (the message was executed by the destination CAL) A result complete code followed by the result value An error code followed by an error number The result message format and error message codes are discussed in detail in Chapter 7. Figure 6.7 illustrates the action of the MTE in the sending and receiving node, as well as the packets generated during an explicit_invoke service request. The figure indicates the cause-and-effect actions that take place in each layer for each step of the message transfer. Time is indicated vertically (that is, time passes from the top to the bottom of the figure). The transmitting node MTE receives a request to send a message2 and builds an APDU indicating explicit_invoke service with a new invoke_ID. The APDU is then sent (via the Network layer) and the MTE starts a 1.5second MT Response Timer.3 This timer sets the maximum time that the MTE will wait for a response from the destination node before giving up or trying again.
Figure 6.7 Sequence of events for explicit_invoke message request from the receiving node. 2
The MT Element can receive a request for message transmission from either the CAL Interpreter or the device application. However, because requests for explicit_invoke service invariably originate from the application, the application is always shown as the originator of the message in the examples. 3
The minimum recommended time for a reply is 1.5 seconds. This timer can be adjusted based on knowledge of the anticipated packet transmission time. Packets that are routed via Brouters, or that use segmented service, will require longer roundtrip acknowledge times.
107
Protocol
At the destination MTE, the message is received from the Network layer. The APDU is parsed, and the message portion is passed to CAL. If explicit_invoke service is requested, the MTE starts a 100 ms MT Wait Timer. This timer sets the maximum time that the MTE will wait for a result from the CAL interpreter. Assuming CAL returns a result before the MT Wait Timer expires, the MTE builds a Result APDU (using the received ID) with the CAL result, and transmits the APDU via the Network layer. The originating MTE receives and parses the APDU, matches the Result APDU with an outstanding message request ID, and passes the result back to the application. There are several variations of explicit_invoke service that should be understood. The second example, illustrated in Figure 6.8, shows what happens if the destination node result packet is lost (or the transmitted packet never arrived at the receiving node). If a result APDU is not received within 1.5 seconds, the originating nodes MT Response Timer expires and the MTE notifies the application of the failure. It is up to the application to decide what action to take as a result of the failure. Typically, the message is resent. The third example, illustrated in Figure 6.9, shows what happens if the CAL interpreter at the destination takes too long to return a result to the MTE. If generating a result takes longer than 100 ms, the MT Wait Timer expires and the MTE sends a receipt_ack APDU back to the originating
Figure 6.8 Sequence of events when explicit_invoke result packet is lost in transmission.
108
Chapter Six node MTE. The receipt_ack service is intended to notify the originating node that the original APDU was received but a result has been delayed. This APDU says, in effect, “we’ll get back to you.” This prevents the originating node from initiating a retry prematurely. In practice, the MT Wait timer is usually not necessary. It is unlikely a message will require more than 100 ms processing time on the part of the CAL interpreter because messages read or write to variables that are part of the context data structure. This data should always be immediately available. There may be cases, in particular implementations, in which the processor time available to the CAL interpreter is interrupted for more than 100 ms by an application task. The originating MTE, upon reception of the receipt_ack APDU, stops its MT Response Timer and notifies the application. The application can then choose to continue to wait for the result, or continue without the result. When the result is finally received, the originating MTE passes the result to the application.
Figure 6.9 MTE sequence of events for sending a receipt _ack packet when the receiving node CAL element cannot respond within 100 ms.
109
Protocol
Conditional_Invoke Service Conditional_invoke service is identical to explicit_invoke service except for the criteria used by the receiving CAL interpreter to generate a result, and the lack of a receipt_ack from the destination node MTE. Conditional_invoke service requests a response from the destination node(s), if and only if, the transmitted message produces a positive result by the destination CAL interpreter. A positive result means that the CAL interpreter generates a result value based on the received message or performs a requested operation successfully. Any error condition or failure to perform a requested CAL method does not generate a response. Because the destination node MTE does not send a receipt_ack APDU, a response APDU is only sent if a result is generated by CAL. Conditional_invoke service is intended to minimize result traffic, and result processing. It is typically used when the destination address is other than a single node address; that is, where more than one node is used as the destination. This usually occurs when the destination address is a group address or the broadcast address. Conditional_invoke can be used to find out which of many devices on the network meet a certain criteria. For example, a node might transmit a message that says, “If your product class is TV then return your node address.” This enables the node to find the network address of all TVs in the house. If explicit_invoke service is used, all nodes on the network will respond, whether they are a TV or not,4 causing a large number of responses, tying up the network, and requiring the originating node to filter out the undesired results. If conditional_invoke service is used, only the nodes that are TVs will respond. Explicit_Retry Service Explicit_retry service is described in the EIA600 document. It allows the MT Element to contain an automatic retry mechanism (similar to the Data Link layer) to resend a message if an explicit_invoke response is not received and the MT Response timer expires. This MTE service is described in this section but the author recommends that the service be implemented in the application. If a response is not received, simply generate a new MT message delivery request. Because reception and processing of an explicit_retry APDU are optional, it is best to avoid using the service because it may generate a reject response from the receiving node.
4
Nodes that are not a TV will respond with a “false evaluation” result.
110
Chapter Six Explicit_retry is the same as explicit_invoke, but with the addition of an automatic retry service performed in the source MTE. When a result message is not received from the destination node within the time interval of the MT Retry Timer, the MTE retransmits the APDU a second time. The usefulness of the service is illustrated in Figure 6.10. If the original APDU is lost, the MT Response timer expires and the MTE resends the APDU. The remaining operations are the same as for explicit_invoke service. The example in Figure 6.11 is almost the same, except that the cause of the retransmission is the loss of the original Result APDU from the destination node. This causes the original APDU to be resent. The destination node, upon receiving the second explicit_retry message with the same invoke_ID, discards the message (does not pass it to CAL), but resends the Result APDU.
Synchronous Service and the Invoke_IDs The CEBus Application layer operates synchronously with other nodes. This means that a node can only have one outstanding message to the
Figure 6.10
Example MTE sequence of events when an explicit_retry service is used.
111
Protocol
Figure 6.11 Example MTE sequence of events when a Result packet is lost during explicit_retry service.
same node at a time. Before sending another message, the receiving node must have processed the previous message and returned a result (if using explicit_invoke service). However, a node can have several messages outstanding to different nodes. The sending node must keep track of which returned result is associated with which transmitted message. This is where the invoke_ID is used. The invoke_ID field in the APDU Header allows MT Elements to track outstanding invoke operations. The invoke_ID is a 3-bit number (0−7) assigned sequentially to each new explicit/conditional_invoke message sent by the MTE (wrapping around from 7 to 0).5 The destination MTE handling the invoking operation returns the same invoke_ID in any Result, Reject, or receipt_ack APDU. This process allows an invoking MTE to associate incoming responses with a particular invoke. An originating MTE may not use an invoke_ID that is still pending a response from a remote MTE. An MTE that receives a duplicate invoke_ID from the same source address MTE must reject the duplicate invoke. This 5
The invoke_ID for an implicit_invoke service is always set to 7 (111).
112
Chapter Six implies that the MT Element must remember an association between the source address of an explicit-type APDU and the invoke_ID long enough to recognize a duplicate message. The duplicate might be caused by a lost Result APDU. In fact, an association must be kept (in an association table) for each outstanding message sent to a different node address, and for each received request for an explicit service. The received message association must be kept to reject a duplicate request from the same node. The association time should be kept for a reasonable network delay time after a response is returned or a duplicate response is returned (nominally 12 seconds). The transmitted message association must be kept until a result message is returned successfully or until a sufficient amount of time has passed for a response to have been received (network round trip delay plus receiver response time). This time should be longer than the receiver association timer (nominally 20 seconds). This will prevent the transmitter from reusing the same ID to the same node prior to the association being discarded in the receiver.
Reject APDUs A Reject APDU is generated by a destination node MT Element anytime the MTE is unable to process the received APDU. The resultant Reject APDU contains a 1-byte code (in the CAL message position) to indicate the reason for the reject in the returned message. The codes are as follows: APDU type is not supported:
30 Hex
Extended Service APDU types not supported:
31 Hex
The Application layer is busy:
32 Hex
Authentication failed:
33 Hex
The third reject code, Application layer busy, is typically the result of the MTE or CAL Interpreter processing a previous APDU.
When to Use What Service Which Application layer service to use must be determined when a message is sent to the MT Element for transmission. This means that when the application or the CAL Interpreter generates a message, it must furnish, along with the message, all the information necessary to transmit
113
Protocol
the message. This includes the Application layer service, the Network layer service, and the Data Link layer service requests, as well as the destination address of the message. This information exchange between the application and Message Transfer, and between the CAL Interpreter and Message Transfer is shown in Figures 6.12 and 6.13 using C-like function calls. An implementer is free, however, to “hide” the selection of layer services in the protocol layer code by making service selections based on the type of message or destination address. In Figure 6.12, the application is free to generate any type of message using any type of Application layer service. The application must know the destination address as well as the service necessary from each protocol layer. Generally, the application is the only element that originates a message that generates a result (such as requesting the current temperature, or the status of the security system) using explicit_invoke or conditional_invoke service. The reply, from each node addressed, is returned from Message Transfer along with the source address (shown in the rec_reply call). The source address is necessary because it is not always the original destination address of the message that generates the response. The message may have been sent to the broadcast address (for example, to get the node address of all TVs) and generated several replies.6 The CAL Interpreter is more limited. CAL can receive a message to read or write a value to its Context data structure (Figure 6.13). The operations can be conditional based on other values in the Context data structure. CAL can also generate a message (called a reporting message) based on a condition in an object. For example, it can send a Figure 6.12 Interface from the application code to MT code (*message is a pointer to the message to send, *reply is a pointer to the received message).
6
This is one technique for acquiring destination addresses on the network.
114
Chapter Six message any time a light switch changes from on to off, or off to on. The value change will generate a message to set a value in another node, so it will know the state of the light. The message generated by the interpreter does not generate a reply or return any result (excluding any explicit_invoke acknowledgment). When CAL generates a Reporting message, it must know the destination address as well as the service necessary from each protocol layer. The destination address is either obtained from the received message (requesting a result) or is stored in the object that generates a reporting message. The protocol services used are determined from a set of rules built into the interpreter. The rules for using the Application layer basic services by the application and the CAL Interpreter are given in Table 6.3. When an application uses conditional_invoke service, it must be prepared to process Result messages from several nodes.
Application Layer Extended Services The Application layer Extended Services provide message security. Message security means that an unauthorized node (person, hacker, and the
Figure 6.13 Interface from the CAL interpreter to MT.
115
Protocol Table 6.3 Rules for deciding which Application layer service to use for message delivery.
Service
Application
CAL
Implicit_invoke
Use when a response is not desired, or when transmitting to a group or broadcast address.
Use for message reporting when transmitting to a group or broadcast address.
Explicit_invoke
Always use when transmitting to a node address.
Use for message reporting when transmitting to a node address. Used for message delivery confirmation only.
Conditional_invoke
Use when conditionally reading a value from a group address.
Not used.
like) cannot read a message, decode it, and then possibly resend it to duplicate its results. It is intended to prevent unauthorized operation of CEBus devices or unauthorized reading or writing of data in CEBus devices. Message security cannot prevent a person or a device from “jamming” the network to prevent a message from being sent or received. It is difficult to prevent electrical access to the network, but relatively easy to prevent message traffic from being decoded.
Authentication Authentication is an umbrella term for two types of CEBus message security: message sender authentication and message encryption. Either or both services may be used for any message. Authentication provides a means for a destination device to verify the authenticity of a message originating device. This capability allows the node manufacturer to prevent selected data in the node from being written (or even read) by an unauthorized node. For example, CEBuscompliant electric meters contain the current electric rate and accumulated electricity usage for the house. This information can be read by a node in the house, but cannot be changed without knowing the authentication access keys to change the data. This information can be read and written by the electric utility because it possesses the current keys for access.
116
Chapter Six
Authentication Algorithms All secure service code is contained in the MT Element. There are two general forms of authentication algorithms allowed by MTE Extended Service: a one-way authentication algorithm, and a two-way algorithm. The one-way algorithm transmits all necessary information in the APDU for the receiving node to verify the transmitter. The two-way algorithm requires a message handshake between nodes. The goal of either algorithm is to make it impossible for someone (by reading network traffic) to determine how to duplicate the traffic or decode the algorithm and send messages to read or alter secure node data. Both algorithms ensure that the message contains enough randomness that decoding the data is extremely difficult. Two-Way Authentication Algorithm The two-way authentication algorithm requires that two Authentication Keys (S1 and S2) be maintained in each node that uses the algorithm. The keys are stored in the Node Control Object of the Universal Context. S1 and S2 must be known by the node issuing a secure command and the node executing the command. Both nodes must also know the same encoding algorithm, E. E is a predefined encoding function that accepts a key and a random number and then produces a value. When a destination node CAL Interpreter receives a command and the command requires authentication, CAL instructs the MTE to issue a challenge_request APDU. The MTE generates a random number R, and then calculates X E(S1, R), encoding R with key S1. It then sends the challenge_request APDU with X in the Authentication Data field (starting at byte 3) of the APDU (see Figure 6.6). When the originating node MTE receives the challenge_request APDU, it first calculates A E1(S1, X) and then B E(S2, A) and then sends B in the Authentication Data field of the authenticate_response APDU. When the destination node receives the authenticate_response APDU, it calculates R′ E1(S2, B). If R′ equals the original R, then MTE informs CAL and the original command is executed; otherwise, an authenticate_reject APDU is returned with a reject code of 33 Hex (authentication failed). Obviously, both nodes must know both S1 and S2, and the encoding algorithm E. How the nodes acquire S1, S2, and E is up to the manufacturer. One-Way Authentication The one-way authentication algorithm allows authentication data to be passed in the original command request. This service only requires one key, S1, and the encoding algo-
117
Protocol
rithm E, but both nodes must know the same random number R. R must be a random value that changes with time (for example, the time of day). When an originating node knows that a command requires authentication, the application or CAL requests one of the authenticate services from the MTE. The MTE calculates X E(S1,R) and transmits the authenticate service APDU with X in the authenticate data field followed by the CAL message. The destination node MTE calculates A E1(S1,X). If A equals the destination node’s present value of R, the command contained in the message field is passed to CAL for execution. Otherwise, an authenticate_reject APDU is returned with a reject code of 33 Hex (authentication failed). Both nodes must know S1, the encoding algorithm E, and how to calculate a value for R that is the same in each node over a short period of time. Existing techniques for this algorithm use a number R generated from the value of the current time. Because the time in both nodes should be equal over a short period, both nodes can calculate the same value of R.
Encryption Message encryption can be used either with or without authentication. Encryption means that the bits in the message (and any authentication data sent in the APDU) are scrambled using a technique known to both the transmitter and receiver so the receiver can unscramble the bits. Encryption provides an additional layer of security for sensitive messages. If encryption is desired for a message, extended services must be used and the ENC bit in byte 1 of the Extended Service Header byte must be set. The encryption algorithm is specified using the Authentication Algorithm ID field in the second byte. The field may specify an authentication algorithm, an encryption technique, or both.
Using Secure Services Application layer Extended Services are optional and add a significant software burden on the node. They should be used only when message security is an absolute requirement and it is known that the destination node employs it. Message security is used whenever messages or context data contain potentially sensitive data to the homeowner or a utility, such as financial information or the status of a security system.
118
Chapter Six It is easy to get paranoid, especially in today’s scary society, about the security of mundane messages and network information, such as the state of light switches. Fears of hacking a house are exaggerated. It is possible, but the risk is small because the reward-to-effort ratio is large (little reward, high effort). It is one thing to hack an electric meter to steal electricity, and another to turn on someone’s bedroom lights as a prank. The latter can be done with existing technology—houses using X-10 can be easily hacked to turn on or off lights and appliances, and security systems can be easily jammed or defeated. But it just doesn’t happen. It is either too much trouble for limited results (in the case of hacking X-10) or unnecessary (in the case of defeating security systems).
Network Layer The Network layer is responsible for networkwide services across any media used in the home. The Network layer in each node communicates with the Network layer in other nodes, as well as with the Network layer in Routers and Brouters. The CEBus Network layer (NL) interfaces with the Message Transfer Element of the Application layer, and the Data Link layer. The Network layer receives requests for message transmission from the Application layer and notification of received messages from the Data Link layer. The Network layer responsibilities for message transmission and reception are given in Table 6.4. The MT Element makes requests to the NL for APDU transmission using selected NL services. The Network layer then builds the appropriate NPDU Header and forms an NPDU for transmission. The Network layer passes the NPDU to the Data Link layer with a request for required DLL services. Table 6.4
ELEMENT
Sending Task
Receiving Task
Network layer responsibilities
Network
Build NPDU
Parse NPDU
ID Packet Generation
Detect ID packet requests
Optional segmented service
Optional segmented service
Optional flow control
Optional flow control IR/RF duplicate packet rejection
119
Protocol
When an NPDU is received from the Data Link layer, the NPDU Header is parsed and the requested Network layer services are performed (if possible). The APDU is then passed to the MT Element.
The NPDU Header The NPDU Header is built by the originating NL to communicate with the destination NL. It is 1 to 8 (or more) bytes long and reflects the desired NL services requested by the originating Network layer. Figure 6.14 illustrates the NL Header structure. The figure shows, on the left side, the order of each possible byte in the header. Where appropriate, the content of most of the bytes is expanded on the right. This figure is referenced throughout the discussion of the Network layer. The NL Header size depends on the services requested. The first byte shown in Figure 6.14 is the NL Service byte and is the only required byte in the header. It indicates, primarily, the services requested of Routers or Brouters to get the packet to its destination. All remaining bytes are optional and exist only if a corresponding flag bit is set in the NL Service byte. NL Service Byte This section describes the structure and function of each bit field of the NL Service byte. The most significant bit (MSB) of the NL Service byte is reserved for some unspecified “privileged” service. It is always zero. The Routing bits indicate the type of Router and Brouter service requested. Flood Routing (1,1) instructs Routers to route the packet to every allowed medium in the network.7 Directory Routing (1,0) instructs Routers to forward the packet onto only the branches of the network in a direct path to the destination node. Routers keep track, using address tables, of which network addresses are on which side of their two media. If the destination address of a received packet is known to be on the other side (other branch) of the network and Directory Routing is requested, the Router will forward the packet. 7
When an application requests Flood Routing of a packet, all Routers on the network will receive and forward the packet. For this reason, Data Link layer-acknowledged services (described in the DLL section) cannot be used because it requires an acknowledgment from each receiving node, including Routers.
120
Chapter Six
Figure 6.14 Format of the NPDU header. There are one to eight (or more) possible bytes in the header. The bit function of each service byte is shown on the right.
ID Packet (0,1) and Request ID (0,0) are used for NL ID packet operations and are explained in the ID Packet section that follows later in this Network layer discussion. The FP and Ext bits are used for extended services requested of the destination node and are explained in the Network layer Extended Service section. The AM bit indicates Allowed Media. When this bit is a zero (cleared), Routers and Brouters are free to route the packet on all media. When this bit is set, an additional Allowed Media byte follows the NL Service byte (after any Brouter address bytes) to indicate which media are allowed for packet forwarding. This byte has a bitmapped correspondence to each CEBus medium type. Each bit in the byte controls packet forwarding onto the medium for that bit position. A 1 bit enables forwarding; a 0 bit blocks forwarding. These bits take precedence over all other routing decisions. The bit positions correspond to the following media:
121
Protocol Position Medium 20
Power Line
2
1
Twisted-Pair
2
2
Coaxial Cable
2
3
Fiber-Optic Cable
2
4
A/V Bus (medium used by AV equipment)
2
5
RF
2
6
Infrared
The Allowed Media (AM) byte has limited usefulness. If used incorrectly, it will prevent message delivery. It can only be used when a message-originating node knows what medium the receiving node is on and wants to reduce unnecessary network traffic (possibly when using Flood routing). If a message uses Directory Routing, the AM byte is unnecessary. The B2 and B1 bits indicate included Brouter addresses. If either bit is set, a 2-byte Brouter address will follow the NL Service byte (as shown in Figure 6.14). If both bits are set, 4 bytes of Brouter address will follow: the first Brouter address (2 bytes) followed by the second Brouter address (2 bytes). Brouter Addresses and Routing A Brouter is a device that forwards between either IR or RF and any other wired media. The NPDU Header Brouter address fields allow a packet to originate, for example, at an IR device, be picked up by the Brouter in the same room as the originating IR device, be forwarded onto a power line to another Brouter in another room, and retransmitted to an IR device in that room (an ambitious packet). The first Brouter address (B1) is the node address of the Brouter that will forward the packet onto the wired media. The second Brouter address (B2) is used when an IR or RF device transmits a packet that must be forwarded onto a wired media and then forwarded again to either an RF or IR destination. The second Brouter address determines which Brouter will forward from wire back to IR or RF. The Duplicate IR/RF Packet Problem If there is more than one Brouter in a room where an IR device transmits a packet, all Brouters within the line of sight will pick up the packet and attempt to forward it to its destination. This will result in duplicate packets arriving at the destination node. There are two techniques available to IR or RF devices to prevent duplicate packets. The first technique relies on knowing the node address of one Brouter in the room where the transmitting device
122
Chapter Six is being used. If the address of a Brouter able to receive the packet is known, its address may be included in the transmitted packet in the B1 address field of the NPDU Header. This will ensure that the packet is only forwarded by one Brouter. The second technique is used if the address is not known, and requires that the transmitter uniquely identify each packet to the receiver. This is done by assigning a sequential packet number to the packet, and relying on the IR/RF duplicate packet rejection capability of the destination nodes Network layer. The duplicate packet rejection capability is one part of the optional Network layer Extended Services described in the next section. Because this service is optional, it cannot be relied on for duplicate rejection. In practice, there should only be one RF Brouter in a house or apartment because an RF Brouter should be capable of transceiving packets to any RF device in the house. This should reduce the risk of RF duplicate packets. Because IR devices are line-of-sight, there needs to be at least one RF Brouter in each room or space in which an IR device is expected to be used. There may, however, be more than one Brouter in a room because AV devices (TVs, VCRs, and the like) may have an IR Brouter built in. Knowing the Brouter address is an advantage.
Network Layer Extended Services Network layer Extended Services are optional NL services requested of the destination node. Extended Services are only used to handle CAL messages (and APDUs) that are too large to send in one packet, and to handle Brouter duplicate-packet rejection. The Extended Services are the most complex part of the protocol. You can skip this section if you are not interested in segmented service or duplicate-packet rejection. The Need for Segmented Service The total size of an NPDU is limited to 32 bytes. This size limit allows products to implement small, fixed-size buffers at the Data Link layer. This size includes all the CAL message, the APDU Header bytes, and the NPDU Header bytes. Because CAL messages are usually short—8 to 10 bytes—and most Application layer and Network layer services require only one header byte, the 32byte limit is usually not a problem. There are times, however, when large messages are required. This usually occurs when a CAL message is used to read a large data value or when a large text string needs to be sent and the message plus header bytes exceed 32 bytes. In this case, the node has
Protocol
123 two choices to overcome the NPDU size limit. The application can read or send the data in smaller chunks, or the message can be segmented using Network layer segmented service. Segmented service takes a large APDU and breaks it up into smaller packets (called segments) for reassemble in the destination node’s Network layer. Segmented service is an optional Network layer service, and if implemented, comes with or without a flow control service. Flow control adds additional reliability to segmented service by allowing Network layers to periodically keep track of segment transmission progress. It is typically used when the APDU is large (more than 100 bytes) and requires transmission of many segments (more than 6 to 8). Specifying Extended Service Extended Service is indicated by setting the Ext bit in the NPDU Service byte. Setting the Ext bit to 1 means that the NPDU will contain at least two additional extended service bytes: the Extended Service byte and one or more Packet Number bytes (see Figure 6.15). The FP (First Packet) bit is used with the Ext bit to indicate the first segment of a multisegment packet. It is set to 1 to indicate that the NPDU contains the first segment. It is clear (0) for any subsequent segments. This bit is set to one when extended service is not used. Extended Service Byte Description When the Ext bit is set in the NPDU Service byte, an Extended Service byte will follow any Brouter address bytes and Allowed Media byte. The format of the Extended Service byte is shown below for reference.
Figure 6.15 Portion of NPDU header. When extended service is used (Ext 1), the Extended Service byte, along with one or more Packet Number bytes, will be included in the header.
124
Chapter Six
The high order 4 bits (27−24) indicate the type of extended service used and the associated reply types. 1100 Seg_service
Segmented Service. This NL Service type supports segmented service with or without flow control.
0110 Num_Packet
Numbered Packet Service. This NL Service type is used by IR and RF devices to transmit or forward singlepacket messages without including a specific address for the forwarding Brouter. This NPDU type permits the identification and rejection of duplicate packets that result from forwarding by multiple Brouters.
1011 Pos_ack 1010 Neg_ack
Positive and Negative responses from a destination node, used with flow control to indicate either positive reception of a window of packets, or a negative reception (error). Used with flow control only.
1001 No_serv_support
No Service Support. Used as a reply to a segmented service request from a destination that does not support segmented service (because it is optional).
0100 Seg_service_busy
Segmented Service Busy. Used as a reply to a segmented service request to indicate that the destination node is either already in the process of receiving a segmented message and it cannot handle another one, or that its message buffer is full. This indicates a temporary condition, and transmission of the segmented message may be attempted later.
0010 Error_msg_len
Message Length Error. Used as a reply to a segmented service request to indicate that the destination node cannot process the message because its Network layer input buffer size (used to reassemble a segmented NPDU) cannot handle the entire message (calculated as the Packet Number times 32).
The use of the remaining four bits in the Extended Service byte depends on the Extended Service type selected in the first four bits. In general, their use is as follows: M#
Message Number bit. This bit is toggled with each new Application layer APDU. The Message Number bit remains the same throughout all segments of the same
125
Protocol
APDU. The Message Number bit distinguishes one group of segments from another. FC Window
Flow Control bit. Indicates (if set to 1) that flow control is requested. Window Size bits (2). Used only with flow control, these bits define the segment transmission “window” size. Window size is 2 plus the binary value of these bits (therefore window size must be 2, 3, 4, or 5). This field is set to 1,1 if flow control is not used.
Packet Number Bytes At least one or more Packet Number bytes follow the Extended Service byte. The Packet Number bytes are used to indicate the number of segments to follow, or an IR/RF packet number, depending on the Extended Service Type used. When Seg_service is used, the Packet Number byte(s) represent the number of segments to follow. The first segment of a message (denoted by the FP bit) has a Packet Number that is one less than the total number of segments. Packet Numbers decrement with each segment. Zero indicates the last segment. When more than 254 segments need to be sent, additional length bytes are used. The initial byte is set to FFh (255) and the following byte contains the remainder segment count. As many bytes are used as needed until the last byte is less than 255. For example, to pass 600 segments, the segment number of the first packet sent would be FFh, FFh, 5Ch (3 bytes). Each additional segment (599 of them) would decrease the segment number by one. When Num_packet service is used by a node on IR or RF for duplicate packet rejection, the Packet Number contains a unique sequence number to enable duplicate IR or RF packets to be identified and discarded by the destination node. The Packet Number is a free-running 8bit counter that starts at 255 and decrements for each new packet. If an IR/RF packet arrives that has the same sequence number from the same source address within a 5-second window (the maximum network delay), the second (or more) packet is discarded as a duplicate. Segmented Service Example The first example is a simple case using segmented service without flow control. The originating node MTE requests transmission of a large APDU using segmented service. The NL breaks the APDU into three segments.8 This example is shown 8
The CEBus Network layer specification does not specify how the Network layer breaks up the APDU. Each segment can contain any number of bytes less than or equal to 32, but the recommended procedure is to send the largest message possible in each segment.
126
Chapter Six in Figure 6.16. The Figure shows the transmission of NPDUs between Network layers of two nodes. The header shows the NL Service byte, the Extended Service byte, and the Packet Number byte used in each NPDU transmitted. The first NPDU shows the NL Service byte with the FP and Ext bits set to indicate the first segment of extended service. The Extended Service byte shows that Seg_service is being used (4 most significant bits have a value of 12), the M# happens to be 1 (for all segments in this APDU), and the FC bit is clear (no flow control). The Packet Number byte starts at 2. The second segment has the same values except that the FP bit in the NL Service byte toggles to 0, and the Packet Number decrements to 1. The last segment has the Packet Number set to 0 to indicate it is the last segment of the APDU. The receiving NL reassembles the segments into a
Figure 6.16 Example of segmented service showing the action of the Network layer of the sending and receiving nodes. The contents of the NPDU header are shown for each packet sent.
Protocol
127 complete APDU, and when the last segment is received, it passes the APDU to the MT Element. Flow Control Flow control can be used with segmented services. When using flow control, the source and destination node Network layers coordinate the delivery of the segments. Flow control allows the originating node to keep track of the progress of segment transmission during segmented service by requiring the destination node to acknowledge reception of a “window” of transmitted segments. The window, or segment group, can be either 2, 3, 4, or 5 segments, and is determined by the value in the 2-bit Window field in the Extended Service byte. If flow control (FC) is used, the FC bit is set in the Extended Service byte and the Window field is set to the desired window size minus 2 (that is, to have a window size of 4, the Window field is set to 2). Errors, such as missing or out-of-sequence segments, are corrected by having the source back up and retransmit all segments after the last correctly received segment. Upon transmission of window-size number of segments, or the last segment, the NL waits for a Pos_ack or Neg_ack response from the destination, or a timeout condition. After window-size segments are successfully received at the destination node (or the last segment) without error, the destination returns a Pos_ack with the Packet Number set to the last received Packet Number value. The acknowledgment packet contains a null APDU (that is, an NPDU Header only). If a missing or out-of-sequence segment is detected during reception, the receiving node immediately transmits a Neg_ack with the Packet Number set to the last correctly received segment number. The source node then begins retransmitting with the next segment after the last good one. Flow control should only be used when transmitting to a single node, because transmitting to a group would cause multiple positive and negative acknowledgments. It is not possible for a node to then retransmit a portion of segments to one node of the group. Flow Control Examples The second example (Figure 6.17) illustrates the use of flow control. The same APDU as in the first example is transmitted, resulting in the same number of segments, but flow control is used with a window size of 2. The first segment shows the same NL Service byte as the first example, but the Extended Service byte shows that Seg_service is requested and the window size field is set to 0,0 indicating a window size of 2 (size 2 window_size). The Packet Number starts, again, at 2.
128
Chapter Six
Figure 6.17 Example of segmented service using flow control with a segment size of 2. The contents of the NPDU header are shown for each packet sent.
After two segments are sent, the sending NL starts an acknowledgment Wait Timer of 10 seconds and waits for a positive acknowledgment from the receiving node. When the receiving node receives the last segment of a window correctly, it will immediately send a Pos_ack NPDU Header with the Packet Number of the last correctly received segment in the window. When the sending node receives the Pos_ack, it will continue with the next window of segments. In the example shown, there is
Protocol
129 only one more segment. When the last segment is received (Packet Number 0), the receiving node also returns a Pos_ack. The third example (Figure 6.18) shows what happens when one of several possible errors occur in APDU transmission. The example is similar to the previous example but the APDU is longer, requiring more segments and
Figure 6.18 Example of segmented service with flow control showing what happens when one of the packets from the sending node to the receiving node is lost.
130
Chapter Six the window size set at 3. The second segment in the first window is lost and never received by the destination node. The destination node does receive the third segment and immediately detects the Packet Number error. Because it is the last segment of the window, a Neg_ack NPDU response is sent to the sending node with the Packet Number of the last correctly received segment prior to the detected error. The originating node then begins retransmission of the APDU at the segment following the last correctly received segment. Similar error conditions can occur if the receiving node does not receive the last segment of a window. In that case, its Wait Timer expires and a Neg_ack is sent with the Packet Number of the next-to-last segment. This causes the originating node to retransmit the last segment and wait for an acknowledgment as usual.
More on IR/RF Packets and Duplicate Rejection When an IR or RF device originates a packet for transmission by a Brouter to a wired medium, the device NL can either use the node address of the intended Brouter in the NL Header, or rely on the IR/RF duplicate packet rejection algorithm in the receiving node. If it chooses a Brouter address, the transmitted NPDU contains 3 bytes (at least) as shown below.
If the device relies on Extended Service duplicate-packet rejection, then the transmitted NPDU Header contains 5 bytes as shown below.
131
Protocol
Notice that a Brouter address is still inserted even though it is not being used. It is set to the Brouter broadcast address (FFFFh). When a receiving Brouter forwards the packet onto a wired medium, it replaces the FFFF with its own node address. Num_Packet Extended Service is used to indicate that the packet originated on either IR or RF and a Brouter address was not used. The Packet Number byte is set to 255. The Packet Number decrements with each new packet sent to the same destination address within a 5-second window. Duplicate packet rejection software requires, in both the transmitting and receiving side, that the NL maintain a Packet Number/source address association list for each transmitted and received packet. Once the first packet to that address is transmitted, a 5-second timer associated with the destination address is started. If the IR/RF device makes another transmission to the same destination before the timer expires, the Packet Number is decremented by one and the timer is reset to 5 seconds. The Packet Number continues to decrement for each new transmission to the same destination address until the timer expires. After the timer expires, the association is discarded. At the destination node, when an Extended Service NPDU Header arrives with a Brouter address, the node knows the packet originated on an IR or RF media and the duplicate packet rejection algorithm is used. The received Packet Number is compared to the list of previously saved packet numbers. If it is a new packet, a 5-second timer is started for that source address and the Packet Number is saved. As each new IR/RF packet is received, the timer is restarted and the new Packet Number is compared to the list of those already received from that source address. A packet is discarded if it is already in the list. Expiration of the timer allows the Packet Number list to be cleared.
IR/RF Packet Examples The example shown in Figure 6.19 shows an RF packet being transmitted from a hand-held remote control device. The packet is picked up by two RF Brouters in the house.9 The remote control transmitted the packet using the node address of one of the Brouters (the one with address 38). The NPDU Header bytes are shown in the “window” pointing to the RF “energy.” Extended Service is not used. Instead, the B1 bit is 9
Two RF Brouters should not be needed in an average size house. Two are used in the example only to illustrate NPDU usage.
132
Chapter Six set and the Brouter address is included. The packet is routed only by the intended Brouter to the power line for reception by the TV. In the second example (Figure 6.20), the hand-held remote control transmits the same message but does not use the Brouter address (it is not known). In this case, the remote control uses Extended Service for duplicatepacket rejection. Both Brouters pick up the RF packet and route the packet to PL. They substitute their own node address for the FFFF Brouter address in the RF packet. The first packet received by the TV will set up an association table entry with the source address of the hand-held remote and Packet Number 255. When the second packet arrives (well within the 5-second limit), the TV will discover that it has the same association as the first packet from the remote, and correctly discard the packet as a duplicate. The third example (Figure 6.21) illustrates using two Brouters to get a packet to its destination. The RF Brouter picks up the packet from the remote. The packet is using Extended Service. Because two Brouters are
Figure 6.19
Example of routing RF packets when the address of the Brouter is included in the NPDU header.
133
Protocol
Figure 6.20 Example of RF packet routing through multiple Brouters. The NPDU headers of the original IR packet are shown along with the headers of the routed packets from the Brouters.
being used for delivery, two Brouter addresses must be included in the packet (B1 and B2 is set). The first Brouter substitutes its own address for B1 and routes the packet to PL. The second Brouter picks up the packet, substitutes its own address for B2, and retransmits the packet on IR for reception by the TV (the destination node address). The TV knows the complete address return path for any reply message.
ID Packets An ID Packet is a special network management packet used to maintain directory routing tables in Routers. ID Packets must be generated by every node on a power-up condition (only if the node has a valid system
134
Chapter Six
Figure 6.21 Example of an RF packet that is routed to an IR medium via a wired medium. The NPDU header bytes for each packet (RF, wired, IR) are shown.
and node address) after a short random delay period. The random delay period (based on the device’s node address) insures that all nodes on the network do not attempt to transmit their ID Packets at the same time. ID Packets originate in the NL after an indication (via Network layer management) from the node’s application software that a power-up condition has occurred. The NL also generates an ID Packet any time it receives a packet with the Routing bits set to 0,0. This combination indicates an ID Packet request from a Router.
135
Protocol
The ID Packet contains only a 1-byte NPDU Header. There is no APDU in the packet. They originate and terminate in the NL. ID Packets are flood routed through the network by Routers. As the ID Packet passes through a Router, the Router updates its Directory Routing Table entry for that particular address. When an ID packet is transmitted by a nodes NL, the NL sets the destination system address to the system address of the node, and the destination node address is set to 00FF (one of the reserved group addresses of Routers). A typical ID packet is shown in Figure 6.22.
Data Link Layer The Data Link layer (DLL) is responsible for reliable transmission and reception of packets over the attached medium. The Data Link layer in each node communicates with the Data Link layer in all other nodes on the attached medium. The Data Link layer receives requests for NPDU transmission from the Network layer and notification of received symbols from the Physical layer. The CEBus DLL does three things: It builds and parses the complete packet including the DLPDU It executes the channel-access protocol It provides an immediate acknowledged packet delivery service on the attached medium. The individual responsibilities for message transmission and reception are listed in Table 6.5. The Network layer makes requests to the Data Link layer for NPDU transmission using requested DLL services. When an NPDU is passed from the Network layer, the DLL Builds the complete DLPDU Gains channel access using the channel access protocol Transmits the packet serially, one symbol at a time
Figure 6.22 Format of an ID packet.
136
Chapter Six
Table 6.5
ELEMENT
Sending Task
Receiving Task
Data Link layer responsibilities.
Data Link
Build DLPDU
Packet reception
Generate preamble
Packet fragment filtering
Leading zero suppression
Bit error detection
Channel access protocol
FCS detection (TP CX IR)
FCS generation (TP CX IR)
Parsing DLPDU
Packet transmission
Address recognition
Acknowledge packet generation
Duplicate packet rejection
Waits for any required acknowledgment of packet reception and performs a retransmission of the packet if necessary When a complete packet is received, the DLL Checks the packet for completeness and lack of reception errors Compares the packet destination address to the DLL node and group addresses Parses the NPDU and passes it to the Network layer if a match occurs Generates and transmits an acknowledge packet if an acknowledgment packet is required The DLL is the most time-critical protocol layer because it operates in real time to keep up with packet reception and transmission.
DLL Structure The CEBus EIA-600 document divides the Data Link layer into two distinct sublayers: The Logical Link Control (LLC) sublayer, and the Medium Access Control (MAC) sublayer. The division occurred early in the development of the CEBus protocol, mainly because it is how Ethernet is designed and the Committee used Ethernet as a protocol model. As DLL functions were refined over the years, the separation proved a burden and all functions migrated to the MAC sublayer. Today, the LLC serves only as a pass-through layer and is kept only as an administrative convenience. All of the DLL services are performed in the MAC sublayer. This is why much of the Data Link layer terminology refers to the
137
Protocol
“MAC this” and the “MAC that.” Terminology such as the “MAC address,” referring to the device node address, still persists. This chapter refers only to the Data Link layer and avoids the LLC/MAC distinction.
Packet Format The first thing that the DLL does after receiving the NPDU from the Network layer is to build the remainder of the packet. The packet consists of the Preamble, Control field, Destination Address, Source Address, NPDU, and an error-detection Frame Check Sequence (FCS). The format of the packet is shown in more detail in Figure 6.23. The Preamble is an 8-bit random value (randomly derived for each transmitted packet) used for collision detection and resolution during channel access. The Control field identifies the type of packet and DLL services for the packet. The format of the Control field is shown in Figure 6.24. The field is divided into the following subfields: S#
The Sequence Number bit toggles between 0 and 1 for each new NPDU transmitted. This bit is used for duplicate-packet rejection at the Data Link layer when using one of the “addressed” services (described later in this section).
SC
Service Class bit. This bit is currently always 0 for basic CEBus service. Extended service (SC 1) is reserved for some future extended capability such as longer packets, different packet formats, and so forth.
X
The next bit is reserved for future use. It is always set to 0.
Priority
The priority bits denote the channel access priority of the packet. The three priority levels determine how long a node waits to transmit a packet.
Figure 6.23 Packet format showing the contribution of the DLL. An EOF symbol separates each field in the DLPDU header.
138
Chapter Six
Figure 6.24 Content of the DLL control field.
Service
The least significant three bits are used to denote the DLL-acknowledged service requested of the receiving node. There are four basic services and two associated replies. The services are described later in this section.
The Destination (To) address and the Source (From) address follow the Control field. Both of these fields are 32 bits and consist of a 16-bit node address and a 16-bit system address. The system address defines a specific address partition for the home to separate it from addresses used in neighboring homes. The node address is either the unique individual node address of the destination node, a group address, or the broadcast address (0000). A destination address is always required. A source address is only required if the destination node needs to return a reply. If a mess age is s ent us ing Applic ation layer implicit_invoke service, and is not using a Network layer Extended Service, and not using a Data Link addressed service, then the source address can be omitted. The trailing Frame Check Sequence (FCS) is either an 8-bit checksum for packets on IR, TP, or CX, or a 16-bit CRC for packets on RF or PL. For a node on IR, TP, or CX, the DLL is responsible for generating the 8-bit checksum. The checksum is a simple addition of all bytes in the packet (excluding the preamble) with carries discarded. For nodes on PL and RF, the Symbol Encoding sublayer of the Physical layer generates a 16-bit
139
Protocol
CRC as symbols are passed down from the Data Link layer, and appends the CRC to the end of the packet.
EOFs, EOPs, and Leading Zero Suppression All fields of the packet, excluding the NPDU, are variable length and delimited by the end-of-field (EOF) symbol. The packet ends in the end-ofpacket (EOP) symbol following the FCS.10 The EOF symbol allows the DLL to perform leading zero suppression. Leading zero suppression does just what it says. Each field is stripped of any leading (insignificant) zeros prior to the first 1 bit used in the field. This accomplishes a simple data compression on the packet. Leading zero suppression is applied to all fields except the Preamble “Packet format:preamble” and the NPDU. The biggest benefit is gained in reducing the size of the address fields. Each address field (destination and source) is 32 bits, yet most system and node addresses used by devices in a typical home will be less than 8 or 9 bits. A high degree of compression is achieved on these fields, shortening packet transmission time. For example, assume that the destination and source address (decimal) of two nodes are as follows: Source system address
5
Source node address
13
Destination system address
5
Destination node address
27
Without leading zero suppression, these addresses would be transmitted as 0000000000011011 0000000000000101 0000000000001101 0000000000000101
taking 117 Unit Symbol Times (11.7 ms). With leading zero suppression, this is actually transmitted as 11011 EOF 101 EOF 1101 EOF 101 EOF
taking 31 Unit Symbol Times (3.1 ms). 10
For packets on RF and PL, the EOP follows the NPDU because it is generated by the DLL. The Symbol Encoding sublayer appends the CRC after the EOP.
140
Chapter Six At the receiving end, the receiving node DLL does not need to reinsert the zeros because the addresses are used directly or converted to an internal (integer) format.
Channel Access Protocol The DLL performs a simple—and inexpensive to implement—channel access protocol called CSMA/CDCR. It sounds a lot more complicated than it is. A node that wishes to transmit a packet waits until the channel is “clear,” that is, no other packet is being transmitted. It then begins to transmit its packet. If, during the transmission, a collision is detected with a packet being transmitted by another node, the node stops transmission and waits again for another clear period. The technique is a little more complex, but that’s the basic idea. The technique is identical to the technique people use to access a telephone line shared by a number of telephones (such as on a party line, or in a home with multiple phones connected to the same telephone line). When you pick up the line and hear someone talking, you hang up and try again later. CSMA/CDCR stands for Carrier Sense Multiple Access with Collision Detection and Collision Resolution. Carrier Sense Multiple Access simply means that many nodes have access to, and are sharing, the same medium, and sense the state of the medium (for a “carrier”) to know when to gain access. Collision Detection means that each node is capable of detecting when a transmission collision occurs with another node transmitting at the same time. Collision Resolution means that a collision can be resolved in favor of one node. The goal of a CSMA/CDCR protocol is to optimize channel access— to allow as many nodes to use the medium as possible without interfering with each other. The strategy used to optimize channel access can be summarized in three methods (the telephone use analogy is given in italics under each one): 1. Avoid contention. If the channel is in use, wait until the channel is idle. If you pick up the phone and someone is already talking, hang up and try again. 2. If contention occurs, resolve in favor of only one node. If two or more nodes attempt to transmit at the same time, all but one should stop transmission.
Protocol
141 If you and someone else pick up the phone at the same time and attempt to talk, the best strategy is for one of you to hang up and let the other person continue, if you both hang up, the situation will just happen again. 3. If a transmission failure occurs, allow the sending node to retry without relinquishing control of the channel. A node should be allowed to attempt retransmission without contention for the channel. If you pick up the phone and begin talking and someone was already on the line talking, the best strategy is for you to hang up and allow the other person to repeat what they were saying, rather than have you both hang up. 1. Avoiding Contention The best technique to optimize channel access is to avoid contention in the first place. The CEBus DLL access protocol uses three methods to avoid contention. Prioritization of channel access. Each transmitted packet can be assigned a channel access priority. The packet priority is used by the sending node to determine how soon it can contend for channel access after an initial 10 UST quiet period after the last packet. Packets are categorized into three priorities: high, standard, and deferred. High-priority packets can contend for channel access during the eleventh UST from the end of previous packet. Standard-priority packets can contend during the fifteenth UST. Deferred-priority packets contend during the nineteenth UST following the last packet. The three priority start times are illustrated in Figure 6.25. All times shown in the figure are referenced from the receiving node. This scheme insures that high-priority packets will only contend with other high-priority packets to gain channel access. Standard- and deferred-priority packets only gain access if there are no high-priority packets. Deferred-priority packets will only gain access if there are no highor standard-priority packets waiting to transmit. Priority Selection A packet channel’s access priority is determined by the node application. The priority is selected based on the type and use of the message. There are no fixed rules for selecting priority, but the following guidelines should be considered. High priority should be used for packets that involve user feedback events where any delay in packet delivery would cause a noticed delay in a control function. For example, the most critical “user
142
Chapter Six
Figure 6.25 Packet priority is based on the start time of the packet from the time the last transmitted packet ends. High-priority packets can start, followed by standard-priority, and then deferred-priority packets.
feedback” timing occurs when a light switch is turned on or off. The user expects the associated light to turn on or off instantaneously. This is due to past experience with lights. If packet delivery takes longer than about 0.1 seconds, the user detects an annoying delay and may attempt to toggle the switch repeatedly, thinking the switch or light is broken or “flaky.” Similar user feedback situations occur when changing channels on a TV, or turning an appliance on or off. Deferred priority should be used whenever there is no rush to deliver the information and there is no user feedback or time-critical events associated with the packet. Deferred priority can be used by devices such as temperature sensors, thermostats, light-level detectors, or other devices that report changes that typically occur slowly. A difference of a few seconds in reporting that the outside temperature has changed from 78° to 79° is not time critical. Standard priority is used for everything else. Standard priority packets are typically used for routine message traffic that is not associated with user feedback but which requires delivery quicker than deferred priority. The packet priority is transmitted in the Priority subfield of the Control byte even though the information is primarily used by the sending DLL to gain channel access. The priority of the packet is available at the receiving node for use by CAL or the application to set the priority of any reply packet returned to the message orig-
143
Protocol
inator. The reply priority is always the same as the original message priority. Round-robin queuing within priority levels. A queuing algorithm is used within priority levels to prevent higher priority packets from “hogging” the medium. Packet queuing is used to enhance the fairness of channel access priority. A packet waiting for transmission can be in one of two queued priority states: queued and unqueued. When a packet is in the queued state, it can be transmitted at the earliest time available for its priority. If the DLL gains channel access without contention and transmits the packet, it then enters the unqueued state for that priority. This means that the next packet it needs to transmit at the same priority will have to wait an additional 4 USTs prior to attempting channel access. The queued/unqueued intervals are shown on the packet transmission times in Figure 6.25. If, while attempting to transmit in the unqueued state, contention occurs and transmission is stopped, the DLL reverts back to the queued state for that priority. The next attempt to transmit the packet will subtract 4 USTs from the access time. This scheme allows, for example, standard-priority packets to compete equally for channel access with high-priority packets from nodes that have successfully transmitted high-priority packets previously. The same situation occurs between standard- and deferred-priority packets. This technique prevents a node with only high-priority packets (such as a light switch) from dominating channel access and preventing standard-priority nodes from transmitting. Randomization of start delay intervals. A random variable is also used to lower the probability of two nodes trying to transmit at the same time. To increase fairness and further reduce contention, a random number (from 0 to 3) is added to the earliest start UST time of the packet. Prior to packet transmission, once the earliest start time for the packet is determined based on priority and queued state, an additional delay of 0 to 3 USTs is added.11 This delay is shown under the queued/unqueued time intervals for each priority in Figure 11
Calculated as the sum of the least significant two bits of the current Preamble and the least significant two bits of the node address.
144
Chapter Six 6.25. The added random delay reduces the possibility that two or more nodes that are in the same priority/queuing time slot try to access the channel at the same time. 2. Resolving Contention in Favor of One Node If contention does occur, each node should attempt to resolve the contention in favor of one node. The technique used to resolve contention is called SUPERIOR state deference. SUPERIOR state deference is the primary means to avoid contention and is the reason why all CEBus media encode packet data in a SUPERIOR and INFERIOR state. Because the SUPERIOR state can be detected over the INFERIOR state, a node can always detect a SUPERIOR state on its medium when it is in the INFERIOR state. If it detects a SUPERIOR state when it is transmitting an INFERIOR state, it knows that another node is attempting channel access at the same time. The first node to detect the contention stops transmitting its packet and waits until the packet being transmitted is completed. This is best illustrated by the example in Figure 6.26. Assume that three nodes (node A, B, and C) all attempt to transmit at exactly the same time.12 The first thing each node transmits is the packet Preamble “Packet format:preamble,” a random 8-bit value. The first state transmitted by each node is the SUPERIOR state because the idle state of the medium is the INFERIOR state. By random chance, all three nodes begin with a 1. At the end of the 1, they all transition to the INFERIOR state (regardless of the next symbol). Node A’s next symbol is a 0 that will last 2 Unit Symbol Times; node B and C’s next symbol is another 1. Node B and C transition to a SUPERIOR 0 symbol after 1 Unit Symbol Time. Node A, still in the INFERIOR state, detects the SUPERIOR state and halts packet transmission. Node B and C continue. Node B and C then transition to the INFERIOR state. Node C’s next symbol is a 1, and node B’s a 0. The same thing happens at node B. It detects Node C’s SUPERIOR state while still in the INFERIOR state, and halts its packet transmission. Node C continues to transmit its packet without interference. All other nodes on the network will receive Node C’s packet successfully, including node A and B. The contention for the medium was resolved in favor of only one node (node C). 12
”Exactly the same time” means within ±25 s of each other. This is the minimum SUPERIOR State recognition time. Anything more and the SUPERIOR State can be detected by any node also attempting to transmit.
145
Protocol
Figure 6.26 Illustration of what happens during SUPERIOR State deference. The example assumes that three nodes begin transmission at exactly the same time.
3. Allow Retransmission without Relinquishing the Channel The third strategy is to allow the sending node to retry without relinquishing control of the channel if a transmission failure occurs. This is implemented in the DLL acknowledged service technique. The 10 UST channel quiet time after each packet allows the transmitting node to regain channel access if its first attempt at delivering a packet failed. This service is described in the following section.
DLL Packet Delivery Services The DLL provides a front-line packet delivery acknowledgment, known as immediate acknowledged service. This lets the DLL know, within 300 s from the end of packet transmission, whether the packet arrived successfully at its destination on the attached medium (or at a Router that will forward it to its destination on another medium). The destination node transmits a short acknowledgment packet immediately upon successful reception of the original packet. If the packet is not delivered, and/or the acknowledgment is not received, the sending DLL can immediately retransmit the message without relinquishing access of the control channel. There are four basic variations on the service that the transmitting application can choose to tailor the delivery service. Unacknowledged service Addressed unacknowledged service Acknowledged service Addressed acknowledged service
146
Chapter Six Each service is accomplished between the Data Link layer of the source and destination nodes. There are two service categories: unacknowledged service and acknowledged service. Unacknowledged service is used when the destination address is a group address or the broadcast address, or when an acknowledgment is not desired. Acknowledged service enables the sending node to determine the success or failure of the transmitted message to a single node across a single medium. Due to the way the channel access protocol works, acknowledged service can only be used when the destination address is a single-node address.
Unacknowledged Service Unacknowledged service is the absence of an acknowledgment from the receiving node or nodes. The DLL transmits the packet once and no acknowledgment is generated by a receiving node or nodes. This service is similar to the Application layer implicit_invoke service. It is usually used when the packet is sent to a group of nodes from which a Data Link acknowledgment is not possible. The service may be used to transmit to a single node, a group of nodes, or to the broadcast address (all nodes on the network). Unacknowledged service is indicated by the use of unack_request (010) in the Service subfield of the Control byte. The control byte looks like:
The Sequence Number (S#) is not used; instead, it is set to 0, the Service Class (SC) is Basic (0), the priority is set to the desired packet priority, and the service bits are set to Unack_request (0 1 0). A Source address field may be used if another protocol layer requires it, otherwise it is omitted.
Addressed Unacknowledged Service Addressed unacknowledged service is similar to unacknowledged service in that no reply is generated by the destination DLL, but it adds an additional level of reliability. Addressed unacknowledged service requests that the DLL transmit the message multiple times to increase the probability of successful reception. The number of times the DLL may transmit a
147
Protocol
packet is governed by a number of variables kept in the DLL software. The variables determine the maximum number of retransmissions, the minimum delay between retries, and the maximum total time allowed for retries. Basically, the DLL may transmit the packet as many times as it can during a 750-ms maximum window (known as the max_retrans_time). The 750-ms window begins at the start of the first successful packet transmission and includes the time required for the last transmission. The DLL must contend for channel access on each transmission at the priority level of the packet. In practice, this allows the sending node to transmit the packet three or four times at most. Typical DLL implementations usually send the packet twice because this is the maximum number of times that the longest packet can be retransmitted. Addressed unacknowledged service is indicated by the use of the addr_unack_request (1 1 1) value in the Service field of the Control byte. The DLL uses the following Control byte:
The Sequence Number toggles between 0 and 1 for each different message sent to the same node (this is used for duplicate packet rejection, explained shortly). During retransmission of a packet, the Sequence Number remains the same. The Service is 0, the priority is selected by the application, and the Service is set to addr_unack_request. The Source Address must be included for duplicate-packet rejection at the receiving node (this is why the service is called Addressed unacknowledged service).
Addressed Unacknowledged Sequence/Address Associations Because several duplicates of the packet are transmitted to the same destination address, a mechanism must be used in the DLL to reject received duplicates. This is accomplished using the Sequence Number and source address in combination at the receiving node to detect a duplicate packet. This service requires that an association be kept between the destination address and the Sequence Number in the sending node DLL, as well as between the source address and the Sequence Number in the receiving node DLL.
148
Chapter Six The association in the receiving node is used to reject all duplicate packets that the sending node might send in the 750-ms retransmission time. All retransmitted packets will have the same Sequence Number (0 or 1) from the same source address. The association (kept in a received association table) must be kept for 938 ms (1.25 750 ms). This time provides for processing and timing differences between the two nodes. Once this time expires, or a new packet is received from the same node (with a new Sequence Number), the association can be removed. In the sending node, the association must be kept to prevent a new packet to the same node from using the same Sequence Number. The association keeps the destination address with the Sequence Number (kept in a transmit association table) for 1,125 ms measured from the last-transmitted packet to that address. This time insures that the receiver will always release the association first. Addressed unacknowledged service is intended to provide higher reliability for messages to group addresses or the broadcast address. It should not be used when an acknowledged service could be used.
Acknowledged Service Acknowledged service requires that the destination node return an acknowledgment to the sending node if the packet arrives without errors (the FCS indicates no bit errors), and if the destination address matches the destination node or group address. To allow nodes to send acknowledgments without having to contend for channel access, the protocol has a 10-Unit Symbol Time acknowledgment window built into the channel-access protocol. This window is free of other traffic and is used to allow a node to acknowledge reception of the packet that just ended. The acknowledgment, in the form of an Acknowledge packet, must be sent by the destination node within 2 Unit Symbol Times (200 s) of the end of the received EOP symbol of the originating packet. The acknowledgment timing is illustrated in Figure 6.27. The originating node expects to receive the acknowledgment within 6 Unit Symbol Times (600 s) of the end of the EOP symbol of its packet. The time difference is to allow for timing differences in the nodes, turn around times, and propagation delay on the medium. The 200 s is referenced from the receiving node. The 600 s is referenced from the sending node. Therefore, the acknowledgment will arrive at the sending node anytime between the third and sixth Unit Symbol Time. The acknowledgment protocol occurs prior to the earliest access possible by a high-priority packet queued for transmission.
Protocol
149 If, for some reason, the originating node does not receive the acknowledgment by the end of the sixth Unit Symbol Time, it will automatically retransmit the message starting during the seventh Unit Symbol Time without relinquishing control of the channel. This automatic retry is part of the acknowledged service protocol. If an acknowledgment is not returned after the retry, the DLL gives up and reports the transmission failure to the Network layer. Acknowledged service is indicated by the use of the ack_request (0 0 1) value in the Service field of the Control byte. The Control byte looks like
The Sequence Number is not used; instead, it is set to 0. The Service class is Basic (0), the priority is set to the desired packet priority, and the Service bits are set to ack_request (0 0 0). A Source address field may be used if another protocol layer requires it, but it is not necessary for acknowledged service. Acknowledged Packet Format The destination node’s DLL returns an Acknowledge packet if the originating packet was received correctly. This packet (Figure 6.28) has a different form than the normal message packet. The Acknowledge packet contains only the Preamble “Packet format:preamble,” the Control field, an optional Information Field, and the FCS. This packet is generated and used exclusively by the DLL. The Preamble “Packet format:preamble” is the same as an application packet. The control field uses a service of Ack (0 0 0) as shown (Fig. 6.28).
Figure 6.27 DLL acknowledgment packet transmission timing. A 10-UST window is always available after a packet is transmitted to allow the receiving node to generate an acknowledgment without contention.
150
Chapter Six
Figure 6.28 Acknowledge packet format.
The Sequence Number is not used, and the Service Class is 0. The Priority bits are not used; they are set to 0,0. The Service class is Ack (0 0 0). An optional Information field is also returned. This field contains additional DLL status information that may be used by the originating node. The possible values of the information field vary with the Service type used. For acknowledged service, only a value of zero (meaning success) is used. Because leading zero suppression is applied to all fields except the Preamble “Packet format:preamble,” both the Control field and the Information field become null. The resulting Acknowledge packet is therefore just [Preamble, EOF, EOF, FCS]
Fail Packet If the destination node receives the packet correctly, but cannot process the packet for some reason (it may be in an error condition or trying to recover from an error condition), a Fail Acknowledgment packet is returned. This will prevent the transmitting node application from retransmitting to the same node repeatedly. The Fail packet is similar to the Acknowledge packet, but the Control and Information fields always contain a non-null value. The Control field contains 1, 0, 0 in the Service subfield. The information field contains one of the two values shown in the following table
Information field value
Condition
Cause
01
Remote Busy
Packet received successfully, but receiving node is busy and cannot process the packet now.
80
Remote Reject
Packet received successfully, but receiving node unable to process packets.
Either returned value indicates that the destination node did not process the packet. The sending node must report the failure to the Network layer.
Protocol
151 Addressed Acknowledged Service Addressed acknowledged service combines the immediate retry service of acknowledged service, with the multiple packet transmission feature of addressed unacknowledged service. Addressed acknowledged service uses the same immediate retry mechanism used by acknowledged service. The destination node must transmit a reply. If the reply is not received within 6 Unit Symbol Times, the sending node retransmits the message starting at the seventh Unit Symbol Time. Unlike acknowledged service, if an Acknowledgment packet is not received after the immediate retry, the DLL can attempt another delivery. It must, however, repeat a normal channel access cycle to retransmit (that is, it must compete with other nodes for channel access after the 10-unit Symbol Time channel-access quiet time). The DLL may attempt to retransmit the packet as many times as it can during the 750-ms max_retrans_time. The 750-ms retransmit time starts at the beginning of the first successful packet transmission and does not expire until the last transmission is complete. The DLL must contend for channel access on each transmission at the priority level of the packet. In practice, this allows the sending node to transmit the packet three or four times at most. As in addressed unacknowledged service, typical implementations chose to send the packet twice because this is the maximum number of times that the longest packet can be retransmitted. Addressed acknowledged service is indicated by the use of the addr_ack_request (1 0 1) value in the Service subfield of the Control byte shown below:
The Sequence Number (S#) toggles between 0 and 1 for each different message sent to the same node for duplicate-packet rejection. During retransmission of the same packet, the Sequence Number remains the same. The Service class (SC) is 0, the priority is selected by the application, and the Service is set to addr_ack_request. The source address must be included for duplicate-packet rejection at the receiving node. Addressed Acknowledged Sequence/Address Associations Just like addressed unacknowledged service, both the sending and receiving nodes must keep an address/sequence number association. Because several duplicates of the packet may be transmitted to the same destination address (excluding the normal immediate retry), the Packet Number and source address are used by the receiving node to detect duplicate addr_ack_request packets. This service requires that an association be kept between the desti-
152
Chapter Six nation address and the Packet Number in the sending node DLL, and between the source address and the Packet Number in the receiving node DLL. The requirements are identical to the addressed unacknowledged service; the timing requirement for the association is explained in that section. Acknowledged Packet Format Like acknowledged service, the destination node’s DLL returns an Acknowledge packet. This packet (Figure 6.29) is different from the normal message packet. The Acknowledge packet contains only the Preamble “Packet format:preamble,” the Control field, the originating node’s source address, an optional Information Field, and the FCS. This packet is generated and used exclusively by the DLL. The Control field will use a service of addr_ack (1 1 0) as below to indicate it is an acknowledgment to the addr_ack_request.
The Sequence Number is the same as the originating packet. The Priority bits are not used and set to 0. An optional Information field is also returned. This field contains additional DLL status information that may be used by the originating node. The possible values of the information field vary with the service type used. For addressed acknowledged service, the information field return values are shown in the following table.
Figure 6.29 Addressed Acknowledge packet format.
Information field value
Condition
Cause
00
Success
Packet received successfully and processed.
01
Remote Busy
Packet received successfully, but receiving node is busy and cannot process the packet now. Try again later.
80
Remote Reject
Packet received successfully, but receiving node unable to process packets.
100-FFFF
Other
Reserved for future use.
Protocol
153 The data in the information field can be used by the originating node to process a retransmission more efficiently. The Remote Reject condition indicates a failure condition in the receiving node. The Remote Busy condition indicates that the packet was received successfully but that the packet could not be processed. This is similar to a receipt_ack indication in the Application layer. Receipt of either condition will stop the sending node’s DLL from retransmitting the packet. Busy Queuing The Remote Busy indication means that the node is tied up with another packet and cannot process the received node. It is an invitation to attempt retransmission after a delay. This indication may be returned by a node whose Network layer is busy assembling a segmented packet, or from a Router whose output buffer (to the routed medium) is full. When this condition is received, the sending DLL will requeue the packet for transmission in the Busy Queue state. This state adds a delay of 12 Unit Symbol Times to the packet’s existing channel-access delay before attempting channel-access again. This added time gives the destination node time to become unbusy and prevents unnecessary channel traffic. When the access delay expires the packet is retransmitted. If another Remote Busy condition is received, the 12-Unit Symbol Time remains in effect for future retransmissions. If no acknowledgment is received, the delay is set to 0 Unit Symbol Times. DLL Service Support A node’s Data Link layer has some flexibility in choosing which DLL service to use. In general, a node can choose to use any of the four DLL services on transmission, depending on the destination address type. A node must be able to support any of the four DLL services on receive. The following guidelines should be used by the application when requesting a DLL service. Unacknowledged service must be used any time that the destination address is anything other than a single-node address (that is, a group address or the broadcast address). Addressed unacknowledged service provides higher reliability than unacknowledged service, but does require more channel access and generates more traffic. Acknowledged service should be used anytime the destination is a single-node address.
154
Chapter Six Addressed acknowledged service provides higher reliability than acknowledged service. It only requires more channel access if the first packet is lost. Because this should be a low probability, addressed acknowledged service should always be used if implemented. Addressed service not only increases reliability by being capable of transmitting a packet several times, but it can also help eliminate what is called the PL or RF “near-far problem.” As an example of the problem, assume three nodes on the power line: nodes A, B, and C (see Figure 6.30). Nodes A and C are far apart on the network and communication between them is marginal. Node B is somewhere between A and C. If nodes A and C happen to transmit a packet to B simultaneously, and node C’s packet is interfered with during transmission (an interfering low impedance or noise source near node C appears during node C’s transmission), node B will only hear node A’s packet and generate an acknowledgment. The acknowledgment will be received by both A and C. C will assume, incorrectly, that its own packet was received and acknowledged. Addressed acknowledgment prevents this because the source address of the destination is returned in the acknowledgment. A typical DLL implementation need only implement one of the unacknowledged and one of the acknowledged services for transmission.
The Physical Layer The Physical layer is pretty much what is sounds like: it is where the “rubber meets the road” or the “bits meet the net.” The packet assembled by the DLL must be transmitted serially, one symbol at a time, on the attached medium. Arriving packets are received one symbol at a time and passed to the DLL for reconstruction. The Physical layer is responsible for transmission and reception of symbols (1, 0, EOF, EOP). It receives requests for DLPDU symbol trans-
Figure 6.30 Simple example of near-far problem.
155
Protocol
mission from the Data Link layer and sends notification of received symbols to the Data Link layer. The CEBus Physical layer does four things: It provides symbol timing. It detects valid symbols on reception. For PL and RF media, it adds a 16-bit CRC at the end of the packet on transmission and checks the CRC on reception. It keeps the DLL informed of the current state of the medium for the DLL’s access protocol. The Physical layer is really two separate parts, which were formally called the Symbol Encoding sublayer (SES) and the Medium Dependent Sublayer (MDS). The Medium Dependent sublayer consists of physical hardware that is dependent on the medium used by the node. It consists of whatever components or chips are necessary to electrically generate the SUPERIOR and INFERIOR states on the medium. The Symbol Encoding sublayer may or may not be physical hardware, depending on the medium and the implementation. Implementations of the Physical layer, including the Symbol Encoding sublayer, for PL and RF are typically all done in an IC.13 The simpler Physical layers for CX, IR, and TP typically implement the Symbol Encoding sublayer in the same microcontroller where the DLL resides. The individual responsibilities for the two sublayers are summarized in Table 6.6.
Table 6.6 Physical layer responsibilities
ELEMENT
Sending Task
Receiving Task
Symbol Encoding Sublayer
Symbol encoding
Symbol decoding
Symbol timing
Bit-error detection
CRC generation (PL, RF)
Channel state detection CRC checking (PL,RF)
Medium Dependent Sublayer
13
SUPERIOR/INFERIOR state generation
SUPERIOR/INFERIOR state detection
Medium interface
Medium interface
Typical of all hardware implementations are Intellon Corporation’s spread-spectrum IC’s for PL and RF.
156
Chapter Six When the SES receives symbols from the DLL, it performs the symbol timing. It alternately generates SUPERIOR and INFERIOR states, and must turn on the Physical layer for the correct amount of time to generate a SUPERIOR state and an INFERIOR state. The timing of the symbols is given in the following table.
Symbol
Transmission timing
Reception timing
1
100 s
50 to 150 s
0
200 s
150 to 250 s
EOF
300 s
250 to 350 s
EOP
400 s
350 to 450 s
Any state of the medium less than 50 s or greater than 450 s is assumed to be a bit error. As well as encoding and decoding symbols to and from the DLL, the SES must also inform the DLL of the state of the medium so that the DLL can implement its channel-access protocol. When the medium enters the SUPERIOR state, the SES informs the DLL that the channel is active (in the SUPERIOR state). When the medium enters the INFERIOR state, the SES informs the DLL the channel is quiet (in the INFERIOR state). The channel quiet indication is passed to the DLL each Unit Symbol Time that the channel remains in the INFERIOR state (this is so the DLL can count channel quiet time). On media other than PL and RF, the state detection must occur within the first 25 s of the start of the state on the medium. On PL and RF, because the symbols use a spread-spectrum carrier, detection of a valid state can only occur after the complete arrival of the state symbol. Therefore, detection of the state occurs after the arrival of the previous state (that is, the SES is always one symbol behind the medium).
The PL and RF Medium SES The PL and RF SES calculate a 16-bit CRC FCS and appends this value to the end of the packet. All bits of the packet, excluding the Preamble “Packet format:preamble,” are used in the CRC calculation. Starting with the first bit of the packet, the SES calculates the CRC starting with the first bit following the Preamble. After the DLL sends the final EOP
157
Protocol
symbol of the packet, the SES appends the additional 16 bits that comprise the packet’s FCS. At the receiving node, starting with the first bit following the preamble, the SES calculates the CRC of the arriving packet, symbol by symbol. After the final EOP is detected by the SES, it takes the following 16 bits as the packets FCS and compares the received value with its own computed CRC on the received packet. If they match, the SES informs the DLL of a successful match. The DLL then assumes that the packet is error free. If the CRCs do not match, the SES informs the DLL of a “bad packet” and the packet is discarded by the DLL.
CEBus Addresses Device addresses are one of two CEBus resources; the other resource being Data Channels. A device’s address is made up of two parts: the system address and the node address. Together, they comprise the device’s complete address on the global network. Every CEBus node must have a system and node address before it can operate properly on the network.
The System Address The device system address (SA) is a 16-bit number in the range of 0 to 65,536 (0 to FFFF hex). The system address is used to partition the address space of devices in one home from devices in another home or apartment residing on the same medium (such as RF or PL). The system address is often called the “house code” because its primary function is to identify the house address.14 There can be more than one system address in a house or apartment, although this makes device installation more challenging. The system address range is divided into reserved and nonreserved ranges as shown in Figure 6.31. Address zero (0000) is reserved as the system broadcast address. A packet that is addressed to SA 0000 will be received by all nodes on the global network; that is, all nodes that can hear the packet, regardless of their current system address. 14
”House code” is also the term that X-10 uses for part of its module addresses that serve the same function.
158
Chapter Six
Figure 6.31 System address range.
Addresses in the ranges 0001 to 7FFF and 8001 to EFFF hex are available for use as individual system addresses. Address 8000 hex is reserved for use by any node performing address acquisition (see Chapter 7 for an explanation). Addresses in the range F000 to FFFF are reserved for some future use.
The Node Address The device node address (NA) is a 16-bit number in the range 0 to 65,536 (0000 to FFFF hex). The node address identifies a unique device within a particular system address. Each node address within a system address must be unique. The NA is often called the MAC address because, along with the system address, it is stored in the Medium Access Control sublayer of the DLL. The node address range is divided into reserved and nonreserved ranges as shown in Figure 6.32. Node address zero (0000) is reserved as the broadcast node address. A packet that is addressed to NA 0000 will be received by all nodes in the house with the same system Address ranges 0001 to 00ED, 1001 to 7FFF, and 8001 to EFFF are available for individual node addresses. Addresses 00FE and 00FF are Router broadcast addresses. These addresses are used by Routers to distribute Router configuration messages. Addresses 0101 to 0FFF are reserved for group addresses (allowing 3,839 groups per system address). Group addresses are a special class of node addresses that can be shared by more than one node. They allow the formation of a logical group of devices addressable with one address. Group addresses are optional, and a device can acquire as
159
Protocol
Figure 6.32 Node address range.
Node Broadcast Address
many group addresses as it has the memory to hold. The example shown in Figure 6.33 shows two groups of outside lights on a house. One group has group address 0102 hex, and consists of all the outside lights. This group is controlled by the light switch on the right. Every node in this group has the same group address in addition to its own unique node address (all these nodes are assumed to be in the same system address). The other group has group address 0114 hex, and consists of the outside lights that are on the front of the house. These lights are controlled by the light switch on the left. Three of the lights are in both groups; that is, they are outside lights and front lights. The remaining two lights are in only one group, the outside lights that are not on the front. The center light (NA 2005), for example, will respond to messages with a destination address of 0102, 0114, or 2005. There is no priority of addresses; it will respond equally to a message from either the left or the right switch. The light simply performs the last message received. Group addresses allow several devices—outside lights in this example— to be controlled by a single message using a single address. The controlling device need only store one destination address. Group addresses are a powerful tool for gaining channel efficiency and flexibility.
160
Chapter Six
Figure 6.33 An example use of group addresses for lights. Each light switch transmits packets to a different group address.
Acquiring and Keeping Addresses A node must acquire a valid (that is, non-zero) system and node address when installed in a CEBus network. A device can optionally acquire as many group addresses as it is capable of acquiring. There are two basic techniques for acquiring the system and node address: self-acquisition and directed acquisition. Self-acquisition means that a node acquires its own address over the network. Directed acquisition means that another node on the network tells the node what address to acquire. Both techniques are explained in Chapter 7. Group addresses are inherited; the “inherit” command is used to tell a node to “join” a group (that is, add a group address). Nodes can leave a group by being sent a “disinherit” command with the group address to leave. This causes the node to remove or “forget” the group address. Once addresses are acquired (node, system, group) they must be kept in nonvolatile memory. Addresses must be retained when the device is not powered or removed from the network. A node keeps its addresses until given a new address, or until it is “reset” in some way that causes it to return to the factory default condition of no address. Nodes may also need to acquire the addresses of other nodes. In the example of the outside lights, the light switches acquired and retained
161
Protocol
the group address of the light group they control. The addresses of other nodes are acquired the same way as the device addresses, by selfacquisition or directed acquisition. Application software in a node may locate nodes on the network it wishes to communicate with, or another device on the network (a controller or configuration device) may get the address(es) and download it into the appropriate node. In either case, the addresses are stored in the application software of the node (in the case of self-acquisition), or in the CAL Context/Object data structure reporting variables (in the case of directed acquisition). Regardless of where it is stored, the addresses of other nodes must also be nonvolatile.
Implementation Issues The description of the protocol layers given in this chapter generally follows the description given in the EIA-600 document. As mentioned at the beginning of the chapter, the description of the protocol is intended to represent a model in which each layer operates independently from other layers, and communication between layers is by a set of “service primitive” calls with arguments. Timing of events within each layer is also treated independently. In practice, the functions of each layer are closely interrelated, and an actual software implementation can combine timers, buffers, and overlapping error conditions. The EIA-600 protocol parts describe a protocol behavior. They are not intended to describe an implementation. A CEBus-compliant node, when tested for proper operation, must exhibit the specified protocol behavior in terms of packet construction, correct use of packet fields, and correct transmission and reception timing. How the behavior is actually achieved is up to the product developer. The following implementation guidelines may be helpful. Each protocol layer maintains several event timers. These timers should be closely coordinated. For example, the explicit_invoke Wait Timer in the Application layer MTE should take into account the services used at lower layers (Network, and Data Link). If segmented service is used, the transmission time of a packet will be multiplied by the number of segments sent and/or received. Many timers can be combined into a set of general timer registers, used as required by each layer.
162
Chapter Six Message-association tables used in each layer can generally be allocated from one association table “pool.” If large messages are supported in the node (where segmented service is used), only one message buffer is needed (for each direction), and that buffer can be shared by the Application layer (MTE and CAL) and the Network layer. Typical implementations of the protocol make the entire packet (DLPDU) available to each layer, from origination at the application or upon reception by the Data Link layer. The packet fields define the services required by each layer.
Layer System Management The EIA-600 protocol layer description relies on an element called layer system management that coordinates the global operation of the protocol software layers, and handles conditions such as startup and reset conditions, errors, and other management tasks. In practice, layer system management software is the node appellation software—that part of the application software that interfaces to the protocol code to manage its operation. Some of the required tasks of layer system management are given in the following list. Setting the protocol software to a known state upon powerup or reset. This includes clearing and setting buffers, timers, tables, and the like. Resetting the protocol software to a known state if a nonrecoverable error condition occurs in the protocol. Causing the Network layer to generate an ID packet on powerup or reset. Transferring any new system, node, or group address from the CAL Context data structure to fields in the Data Link layer (for use by the DLL for address comparison). Setting temporary system and node addresses in the Data Link layer during address acquisition. It is also responsible for any housekeeping task that is not isolated to a single protocol layer.
Chapter Seven The message portion of the packet (the message portion of the APDU) contains the CAL commands. The CEBus Common Application Language (CAL) provides a comprehensive command syntax for residential product control. CAL defines what products say to each other. By establishing a common product model and common set of commands, residential products are able to communicate with other products without knowing how each specific product operates, who built it, or what’s in it. The name CAL is really a misnomer because it is not a formal programming language like C or Pascal.1 CAL consists of two major parts: the definition of a data structure that models product operation, and a command syntax that defines the operation of a set of methods on the data structure. Although CAL adheres to many object-oriented principles typically found in languages such as C, it is not an object-oriented language. CAL messages originate from, and are received and parsed by, the CAL interpreter. The CAL interpreter is an element within the Application layer. It provides services to the application, including resource allocation and control functions. CAL, in turn, uses the services provided by the Message Transfer Element (MT Element) of the Application layer to communicate with other nodes.
CAL Goals CAL’s design requirements were determined early in its development by the CEBus Language Working Group: It must be common among all residential devices. CAL’s strength is its capability to model and control any consumer device found in the home through a common set of data structures. These predefined data structures ensure application-level interoperability. It must allow both control and data acquisition functions. Devices must be capable of performing control functions, and to acquire data from other devices, either actively by asking for the data, or passively by providing a destination for data broadcast on the network. It must allow network management administration and management functions. All of the “housekeeping” functions required by a node 1
When CAL was originally developed, it was intended to be a programming language. The purpose and syntax was later changed to a command “language,” but the name stuck.
165
CAL
must be performed by the language. Tasks such as acquiring an address, allocating resources, finding out what devices are on the network, configuring other nodes, and the like, can be performed by any node using CAL. It must be reusable and extensible. The independence of Context operation allows CAL to adapt easily to future products in the home without having to foresee every conceivable new product. If new products require some new Context (a toastwasher, for instance), then a new Context can be created. It must be customizable. A manufacturer must be capable of handling unique product functions not provided in the published CAL specifications. The syntax must allow the use of manufacturer-developed Context and object data structures, as well as custom commands, while still being assured that they will not interfere with or be interfered with by other nodes on the network. It must be easy to implement in common microcontrollers. A CAL interpreter and data structure must be capable of being coded and must run efficiently in 8-bit microcontrollers with memory space available for the protocol and application code. It should be possible to add necessary CEBus software to existing microcontrollers in existing applications without the need to add additional processors. Manufacturers must be free to trade-off complexity for speed and available memory resources depending on the application. All of these requirements have been met. CAL, and all other CEBusrequired components, have been implemented successfully in devices as simple as a light switch and as complex as wide screen TVs.2 CAL can be implemented at a reasonable cost in any consumer product.
How CAL Models the Consumer Product World It is not possible to know how to operate all consumer products in the home over a network. There are just too many different kinds of products. 2
A light switch is considered to be a “lowest form of life” product. It is used as a benchmark for determining the minimum requirements that a CEBus device must meet.
166
Chapter Seven A more logical approach is to analyze all of the functions that consumer products perform and try to find a commonality, by product category, among those. CAL’s design is based on the assumption that all electrical appliances and products in the home have a hierarchical structure of common parts or functions, and that the basic operation of the common functions is the same from product to product. CAL treats each product as a collection of one or more of these common parts called Contexts. Contexts are designed to allow access to product functions in a uniform way. They are designed to work together over the CEBus network to implement Application layer interoperability between products.
The Context Data Structure The CAL Context data structure is a software model in each CEBus-compliant product that models the operation of all the functions available in the product. The data structure is defined by the Context definitions in EIA-600 and the Context documents published by the CEBus Industry Council.
Contexts A Context defines a functional “subunit” of a product whose operation can be defined and remains the same regardless of where it’s used. A typical example of the Context model can be found in a CEBus-compliant TV. A television is too general a product category to be modeled directly because TV is not specific enough. Some TVs have a clock, some have an audio amplifier, some a tuner, and some have built-in surround sound. TVs, however, are made up of one or more audio/video functions such as tuning, video display, audio amplification, and so on. E ach individual function can be well defined. Any CEBus-compliant TV, therefore, can be modeled as a collection of Contexts at a network node address (see Figure 7.1). Depending on the features of the model, a CEBus-compliant TV might contain a video display Context, an audio amplifier Context, a tuner Context, a clock Context, a user interface Context, and so on.
167
CAL
Figure 7.1 CEBus nodes consist of one or more Contexts. Each Context defines a generic product function.
CAL defines over 60 different contexts for everything from lighting, security, and heating/air conditioning to washing and drying. Each Context, regardless of what product it’s in, operates the same way. The audio amplifier in the TV, stereo receiver, the speakerphone, and the intercom all work alike. If a CEBus product knows how to set the volume in the audio Context in one product, it knows how to set the volume in all CEBuscompliant products. The current list of CEBus Contexts is given in Table 7.1. The list is organized by Context class number and by industry group. Because Context development is a continuing activity, the list is changing and growing. For the most current list, contact the CIC. The section “Where Do Contexts Come From,” later in this chapter, discusses the development of Contexts. Two other Context industry groups exist for future context development: Communications and Computers.
Objects As shown in Figure 7.2, each Context consists of one or more objects. An object represents a software model of a control function of a Context. In the figure, only 4 of the 20 objects used in the actual CEBus Audio Context are shown. The volume, bass, and treble analog control objects, and the mute binary switch object represent control functions typically found in audio amplifiers. Objects model tasks performed by users to control a product. To turn a light off or on, you use a two-position switch (off and on positions) defined in CEBus as a Binary Switch Object. To adjust the volume on a
168 Table 7.1
Existing CEBus Contexts
Chapter Seven Class
Context Name
Class
Context Name
General
Utility
00
Universal
50
Utility Metering
02
User Interface
51
Utility Monitoring
04
Data Channel
54
Load Center
05
Time
55
Load Center Control
56
Energy Control
57
Energy Management
Audio/Video
Security
10
Audio Amp
60
Security Sensor
11
Medium Transport
61
Security Zone
12
Tune
62
Security Partition
13
Video Display
63
Security Partition Control
14
Audio Equalizer
64
Security Alarm Status
15
Camera
65
Security Alarm
17
Switch
18
A/V System
19
A/V System Control Lighting
Appliance
20
Light Sensor
70
Washer
21
Light
72
Water Heating
22
Lighting Zone
73
Dryer
23
Light Status
74
Refrigerator/Freezer
24
Lighting Zone Control
75
Range
76
Oven
77
Coffee Maker
Environmental Control
Convenience
40
Environmental Zone
80
Window
41
Environmental Sensor
81
Window Control
42
Environmental Status
82
Door/Gate
169
CAL Table 7.1
Existing CEBus Contexts (Continued)
Class
Context Name
Class
Environmental Control
Context Name
Convenience
43
Environmental Zone Control
83
Door/Gate Control
44
Environmental Zone Equip.
84
Pool/Spa
45
Environmental System
85
Pool/Spa Control
46
Damper Control
86
Bath
87
Fountain
Figure 7.2 Each Context consists of a set of objects. Objects model the control functions of the Context.
stereo receiver, or to raise or lower the temperature on the thermostat, you use a control (knob), defined in CEBus as an Analog Control Object. All analog controls are similar; they have minimum and maximum values, and can be set to any value between. Other controls found on consumer products include multiposition switches (such as the switch that selects the audio source on the stereo receiver) and keypads. In addition to control objects, sensor objects provide information about a product function such as temperature, position, level, or time. Analog sensors, such as temperature sensors or light-level sensors, are the sensing equivalent of an analog control—they have minimum and maximum values, and can assume any value between. The definition of an object is generic, modeling a general class of control or sensing tasks. However, when an object is used in a specific context, it assumes a specific instantiation of a function of the Context, such as volume or temperature control. In the previous example of the TV, the audio amplifier Context shows a binary switch object for mut-
170
Chapter Seven
Figure 7.3 Icon representation of the objects used to model the various control and sense functions of a context. The diagram of each object contains its class number and name. When used in Context diagrams, the object name is replaced with the name of the object function.
ing, and three analog control objects for volume, bass, and treble. These represent instantiated uses of the Binary Switch object, and the Analog Control object for this application. CAL has 23 predefined object models available for use in making Contexts. Figure 7.3 shows a graphic representation of each of the 23 objects.3 Each object in the figure is labeled with the name of the object and its class number, and an icon for easy identification in Context diagrams. The purpose of the arrowlike shape of each object is explained later in this chapter and in the section on object binding. Certain objects handle functions unique to CEBus-compliant products such as the Data Channel Receiver and Transmitter, and Node Control and Context Control objects. The Node Control and Context Control objects provide storage locations for information about the product and implemented Contexts. 3
The EIA-600 CAL specification lists 29 objects. However, several of the objects (Ganged Analog Control, for example) are left over from earlier versions of CAL and are not recommended for new product design.
171
CAL
Object Definitions Objects are defined by a set of instance variables (IVs), as illustrated in Figure 7.4, that specify the operation of the control or sensing function of the object. The Binary Switch object shown in the figure contains a variable (current_position) that indicates whether the switch is on or off, the default position (default_position) of the switch, and several other optional IVs. IVs are just like variables in any software program, having a length or size and a data type. All network operations on Contexts are performed by reading or writing to object IVs. The IVs that define an object are listed in the object tables in the CAL specification. There is a table for each of the 23 objects. Appendix A contains a version of the CAL object tables. Figure 7.5 is a copy of the Analog Control object table. The object class and name are given on the top line. The description section gives the general intended use of the object including any restrictions, special use information, or recommendations. The description is followed by a listing of all IVs defined for the object class. The IV list contains the label, storage class, data type, name, and description. Any IV label and name in bold type (such as the current_value in the table) represents a required IV in the object. If the object is used, the required IVs must be supported per the requirements of EIA-600 for the data type. IV Categories The IVs in an object can be categorized into three general groups: support IVs, reporting IVs, and active IVs. Support IVs are usually read-only variables that define the installation use of the object and operation of the active IV. These values usually define the units of measure, minimum and maximum values, or other attributes of the active IV. Their use is almost always optional, and they provide other nodes on the network more detailed information about a product’s operation. In the analog control object in Figure 7.5, the first
Figure 7.4 An object consists of a group of instance variables that define the operation of the object.
172
Chapter Seven
Figure 7.5 Analog Control object table as given in the EIA-600 document. The table contains an entry for each IV showing the IV label, access, data type, name, and a description of the use of the IV. This figure illustrates the general categories of IVs in the object: support, active, and reporting.
group of IVs fall into this category. They are optional, read-only IVs used to define the behavior of the active IV. The active IV (or IVs) of an object is the variable that is primarily set or read to operate the object. This variable is usually called the current_value, current_position, or current-something. It is always required and contains the state or value of the object. It may be read-only or read/write. The reporting IVs are always present if an object is capable of generating a message via the CAL Interpreter using object reporting. These IVs contain the reporting address, condition, and message fragment (header) information necessary for the CAL interpreter to know when and where to send the message. Reporting IVs may be read-only or read/write depending on how the IVs are to be configured (at the factory or in the field). IV Labels In each object table, IVs are identified by an ASCII label in the left column. IV labels are an ASCII string of one or more characters. The object definitions use a set of reserved one-character labels, indicat-
173
CAL
ed by uppercase, for IVs that commonly occur in most objects. The remaining IVs in each object, unique to the object, are labeled using lowercase letters. There are only a few, seldom used, IVs that require more than one character. Read/Write Access IVs are specified as either read/write or read-only. The access is referenced from the network, not internally from the product application software. In Figure 7.5, the second column indicates which IVs are read-only (R), or read/write (R/W). For example, the units_of_measure IV, U, is read-only, meaning that other devices on the network can read the IV but cannot change it. The current_value IV, C, can be read or written by other nodes. If an IV is specified as R/W in the standard, it must be implemented as read/writable, but if an IV is given as R, it can be implemented as read-only or read/write at the discretion of the manufacturer. Write-only IVs are allowed but, as of the writing of this book, none have been defined. IV Data Types IVs have a data type just as do variables in a programming language. In CAL, there are four data types: Boolean (b), numeric (n), character string (c), and data (d). The third column in Figure 7.5, indicates the data type of the IV. For example, the units_of_measure IV is numeric. The following paragraphs define the data types and indicate how the data is represented in IVs and in a CAL message. A boolean variable can hold one of two values: 0 or 1 hex, corresponding to False and True respectively. Boolean values are transmitted in a message as a 0 or 1 hex byte.
Boolean
A numeric variable may contain any numeric value; integer or real. Numeric values are always transmitted in a message as an ASCII string of the general form ±n.nE±n, where n is any sequence of digits (ASCII characters 0 to 9). For example, the number 35.8 is transmitted as ASCII characters , 3, 5, ., 8. The standard recommends that numbers that can be represented by four or fewer digits be transmitted in the form ±n.n. Numbers longer than four digits may be exchanged using scientific notation. For example, 1788 and 89.55 are transmitted as shown, while the number 0.00008 may be transmitted as 8.0E-5.4 Numeric
4
The range of numbers needed to control consumer products is small and rarely exceeds values that can be represented by four digits. Most numbers can be stored as signed values in 1 byte (127 to 128).
174
Chapter Seven How numbers are represented in a product is not specified. Numbers may be stored as integer or real values at whatever precision is sufficient for the application. For example, if an IV value is stored internally using 8 bits, and the number 24.39 is received, only 24 (the integer portion) is used and retained. The range of values a particular numeric IV can assume is usually defined in the Context definition containing the object. It is the responsibility of the manufacturer to hold the specified range of numbers given in the Context definition. Character String A character string is any stream of bytes in the range
of 00…7F hex. This range represents the printable and “control” characters of the ASCII character set.5 A character IV must be capable of holding as many characters as necessary for the application. The length of the string is usually defined in the Context definition containing the object. A character string is transmitted in a message in the form:
The LITERAL token (EC hex) is needed to parse the bytes as a character string where it might be confused as an IV label. Note: In the syntax examples used in this book, anything enclosed in the “< >” characters is an element identifier and may be made up of one or more simpler elements. Anything enclosed in bracket characters “[ ]” is optional. Tokens are a set of reserved bytes in the E0 to FE range that are used in the message syntax to represent predefined operations or to simplify message parsing. Data A data variable is defined as a fixed length block of memory. A
data IV can hold any number of bytes (up to its length) of any binary value 00…FF hex. The application and/or CAL Interpreter must keep track of the length of the last data written and the total length of the IV. Data values are transmitted in a message with a data identifier header indicating the size of the data. The format is: <ESCAPE>
For example, the five bytes 1A 01 4F 45 48 are transmitted as: 5
The standard specifies an “escape” sequence that can be used to handle special characters in languages other than English, such as á, õ, ë, and so on.
175
CAL 35 <ESCAPE> 1A 01 4F 45 48
or F4 35 F6 1A 01 4F 45 48
(the length is a number sent as ASCII characters) Required vs. Optional IVs Each object specification indicates which IVs are required in the object when implemented in a context. Other IVs listed in the object are optional. All required and optional IVs used in an object must conform to the object specification. The required IVs provide operational information necessary to use the object. The current_value exists in most objects and contains the primary modeling parameter of the object. In Figure 7.5, only the current_value IV is required in this object (it is bold); all other IVs are optional. IV Volatility IVs containing CEBus resource information (the system, node, group addresses, and data channel numbers) must be stored in nonvolatile memory and must be retained during a power outage. Readonly IVs, when used, are normally kept in ROM. Read/write IVs are normally kept in volatile memory (RAM). The type of memory used depends on the application and whether the last value in an IV needs to be retained during power loss. For example, the current channel number of the Tuner object is a read/write IV, but it may be necessary to retain the last value of the IV when the TV containing the IV is turned on. The manufacturer should always consider the consequences of losing the value of an IV or resetting the IV to a default value due to a powerout or power-up condition. Using Support and Reporting IVs Generally, read-only IVs are not used directly by the product; they are provided so that other nodes— that care to read them—can determine the specific application of the object. For example, in the Analog Control object in Figure 7.5, the units_of_measure, step_size, step_rate, min_value, max_value, and default_value IVs are used to define the characteristics of a particular use of the object. None of these IVs are required, but they may benefit other nodes for two reasons: The IVs may hold values that differ from the default or recommended values given in the Context specifications where the object is used
176
Chapter Seven The manufacturer provided the values to aid in using the object where no default or Context specification values exist Many objects contain a set of reporting IVs: reporting_condition, report_header, report_address, and previous_value. These IVs are used as a group to determine the conditions that cause an object to send a message to another node. Their use is described in more detail later in this chapter. Manufacturer-Defined IVs The IVs listed in the object tables are the minimum needed to define the operation of the object. However, when an object is instantiated in a Context, additional IVs may be added for a unique function required by the object in a specific Context. These IVs are defined when the Context is created by the working group that developed the Context, and become a permanent part of the object only in that particular Context. Manufacturers may also add additional IVs to an object if their particular product requires them. Additional IVs must behave according to the rules for the IV data type, and not interfere with the function of predefined IVs. IV labels starting with the letters I, J, K, L, W, X, Y, and Z are reserved for manufacturer use only. IVs added by manufacturers exist only in that manufacturer’s product, and are not recognized as part of the CAL specification. Object Instantiation Contexts, like objects, are defined by a set of tables that give the definition of the Context, the Context class, and a list of the objects used in the Context. Contexts contain no data or information other than the objects that comprise the Context. When a Context class is created, object classes are instantiated in the Context. Instantiation occurs when an instance of an object class is given a specific function in a Context, and the IVs take on specific values applicable to the Context. Figure 7.6 shows how the Analog Control object (class 07) is used in the Audio Amplifier Context (class 10). This figure shows the Context table entry for the Volume Control—an instantiation of the Analog Control object. Here the object is given a particular function, that of controlling the volume level of the amplifier. The table entry shows the name of the object (Volume Control), its object class (Analog Control), the function of the object, and the standard list of IVs used in the object. The list includes the IV Context function that gives any specific values or use of the IV in the Context. In this example, the first seven IVs are assigned a specific value or range of values for the volume function. When this object is used in a
CAL
177
Figure 7.6 Analog Control object instantiated in Audio Context as a volume control object.
product with an audio amplifier function, using the Audio Amplifier Context, each IV (if implemented) must use the values shown in the Context table. The current_value IV is the only IV required, and assumes the values 0 to 100 (because the units_of_measure is a percentage of full scale). The current_value range corresponds to the minimum and maximum volume range. Figure 7.7 shows an example of the same Analog Control object when used in a different Context. This example shows the Heating Setting object in the Environmental Zone Context (40). Here, the same object is instantiated for a different function. The same IVs are used, but they assume a different meaning. The current_value IV assumes the function of the current heating setting. When implemented, this IV can only assume values between the min_value and max_value IV values. If a message attempts to set the IV to a value outside this range, an error message (value out of range) is returned to the sender. Error message details are given in the Message Responses section in this chapter. Objects are reusable both within the same Context and across Contexts. By using the same model for different instances of objects, the operation of each object is the same regardless of where it is used. This assures the operation of CAL commands on the same object class in different products will produce the same result. Contexts are also reusable within the same product and across products. If a product knows how to operate an Audio Amplifier function in a TV, it can operate an Audio Amplifier in the intercom, speaker phone, or stereo receiver.
178
Chapter Seven
Figure 7.7 This is the same Analog Control object shown in Figure 7.6 except that here it is instantiated as the Heating Setting object in the Environmental Zone Context.
Context Data Structure The Context and object data structure in a product is designed as a tree structure (see Figure 7.8). The message portion of received packets is directed toward a particular object in a particular Context. Each Context is referenced by its class number, while the objects in each Context are referenced by the order in which they are listed in the Context definition, starting at 01. Objects are referenced, within the Context, by their number rather than their class because there are typically many copies of the same class within each Context. Every CEBus product contains the Universal Context (00). The Universal Context contains the general product data, address, and other productwide information. All other Contexts are optional and depend on the functions that the product supports. Object Implementation Objects are coded as a set of IV data variables, and application software associated with the variables. Figure 7.9 illustrates the interface between the object IVs, the application code, and the CAL Interpreter. Unlike objects in C, or other object-oriented languages, CAL object variables are “exposed” to the network through the CAL Interpreter. The application code that implements the function of the object is hidden. IVs may be thought of as the interface between the product application and the “outside world” of the network. Unless protected, IVs can be read or written by any node on the network. Incoming messages either read the values of the variables or write new values. The application code does the same; it checks for changed values and acts accordingly, or updates the values. The CAL interpreter can be
179
CAL
Figure 7.8 Representation of the Context/object data structure. A device may contain any number of Contexts, depending on the functions that the product supports or interoperates with on the network.
Figure 7.9 Representation of object implementation. The object data structure (IVs) is accessible by the CAL Interpreter and the object application code.
programmed to send any new IV value—changed by the application software or by an incoming message—to any other object on the network, in any product or group of products.
Object Network Types Objects can be divided into three general categories: network output, network input, and network input/output. These categories define
180
Chapter Seven whether the object is primarily a sender of messages, a receiver of messages, or both. Objects are represented by one of three symbols corresponding to the network type.
Network output objects generate messages. The current_value IV is read-only and the object is used to originate report messages. Typical network output objects include the binary sensor, analog sensor, and multiposition sensor. Messages are generated when the obj ect current_value changes by some amount.
Network input objects receive messages. The object’s current_value IV can be set from an incoming message, but it does not generate a message. Typical network input objects include the Meter, Display, and Synthesizer/Tuner.
Network input/output objects can receive or send messages, or both, depending on the application. The current_value IV is read/write (R/W), which can be set from an incoming message. Messages can also be sent based on local current_value changes. The change may be the result of an incoming message, or a local application change. Typical network I/O objects are the Analog Control, Binary Switch, and Multiposition Switch. All of the objects (except the Node Control and Context Control objects) fall into one of the three network type categories, as shown in Figure 7.10. The object type symbols are used to develop Context interconnect diagrams that show the interconnectivity or binding from an object in one Context, to an object in another Context.
Object Binding: How Contexts Work Together Object binding establishes an address correspondence (stored in the object reporting IVs) between a network output object and one or more network input objects. Network output objects always send their output
181
CAL
Figure 7.10 Classification of each object as Network Output, Network Input/Output, or Network Input.
Network Output
Network Input/Output
Binary Sensor
Binary Switch
Analog Sensor
Analog Control
Multiposition Sensor
Multiposition Switch
Keypad
Medium Transport
Counter/Timer
Matrix Switch Clock Dialer
Network Input Data Channel Trans
Motor
Data Channel Rcvr
Synth./Tuner
Meter
Tone Generator
List Memory
Display
Data Memory
to network input objects. For example, in Figure 7.11, the Binary Sensor object in the light switch binds to the Binary Switch object in the light. The output of a Binary Sensor object is always sent to a Binary Switch object. There is no other object that can receive the binary value output of a Binary Sensor object. The only information required for binding by the Binary Sensor object is the system/node address and Context of the destination node. The destination object (Binary Switch) is implied. This relationship between specific object classes is intentional. Most network output objects bind to specific network input (or input/output) objects of the same data type (that is, the data type of the reported IV and receiving IV are the same). Binding also extends to Contexts. Most of the objects in each CAL Context are intended to work (or bind) directly with specific objects in other Contexts. Context binding implies a predefined interoperability between Context classes. A Context interconnect diagram defines Context binding and illustrates how two or more Contexts work together. Figure 7.12 shows a
182
Chapter Seven
Figure 7.11 Example of object binding. Output objects always send messages to network input (or input/output) objects.
Figure 7.12 Context interconnect diagram for two of the HVAC Contexts.
simple example of a Context interconnect diagram for two of the HVAC Contexts. The Environmental Sensor (41) Context is intended to reside in any device that measures temperature and/or humidity. The objects in this Context bind to a set of corresponding network input objects in the Environmental Status Context (42), which is intended to be used in any product that needs or wants to know the inside or outside temperature or humidity. This might be a thermostat, a TV, or a PC. The objects in the Environmental Sensor Context send messages reporting a change in temperature or humidity to the Environmental Status Context—there is no other Context/object for the output message to go. This design makes interconnecting or binding products in the field easy because only the system and node address of the device containing the Environmental Status Context needs to be known. A product designer knows where network output object messages will be sent. The diagram also indicates another important attribute. The diagram removes any ambiguity about which Context supplies information and which Context receives information. A product designer that incorporates the Environmental Sensor Context knows that the product will send new temperature and/or humidity values, rather than wait for another product to read the values. A product designer that uses the Environmental Status Context knows that if temperature and/or humidity is available (another product is measuring it), it will be written to the
CAL
183 corresponding objects. The product does not have to read it. This prevents a situation where one manufacturer assumes the information in his product will be read, and another manufacturer assumes the information will be written, and neither product communicates correctly. Figure 7.13 is a portion of another HVAC Context interconnect diagram. This shows the Environmental Zone Control Context (43) and the Environmental Zone Context (40). The Environmental Zone Control Context is intended to be used in products that need to control heating/air-conditioning equipment. This Context might be in a television, a PC, or a home automation system. The Environmental Zone Context is intended to be used in heating/air-conditioning equipment, in particular, a thermostat or equivalent product. Note that the Environmental Zone Context is bound to another Context not shown (the Environmental Equipment Context (44)). Context 43 is typical of many Contexts intended to be used in control products (that is, products that contain a user interface, or control algorithms, and that allow them to directly control other classes of products). An example is a television or PC with an onscreen menu that allows the user to select the heating and cooling setting for the house. User selections change the values in the Zone Control Context. This causes messages to be sent to the Environmental Zone Context in the thermostat to change its settings. Contexts do not have to bind to or be bound by other Contexts, but Contexts do provide a convenient control model. Many Contexts (the
Figure 7.13 Context interconnect diagram for two HVAC Contexts. Context 43 is intended to be used in non-HVAC products that need to control or monitor HVAC zones. Context 40 is intended to perform the functions normally associated with a thermostat.
184
Chapter Seven Audio Amplifier (10), Time (04), Camera (16), and so on) do not have a published predefined binding with other contexts. They are used “as is,” and any binding must be developed during installation or provided by the manufacturer.6 The Context Development Committee of the CIC is constantly working to develop interoperable relationships between most of the industry contexts. Binding in the Field Binding can occur in one of several ways, depending on the scale and application of the receiving group. Consider, for example, the relationship between a light switch node and a light node in which the light switch controls the light. The Light Level Setting object in the Lighting Context (found in the light switch) is designed to bind to the Light Level Control object (found in the light). For this one-to-one binding between a light switch and light, the Light Level Setting usually binds to the Light Level Control Object in a specific light node or groups of light nodes. This is because light switches usually control a specific light, selected when they are installed. All that is required is the system/node address of the light. The Light Level Setting Object always sends its messages to the Light Level Control object in the Lighting Context. A more general (and desirable) binding exists for many types of consumer products that do not require the destination node address. Figure
Figure 7.14 An example of object binding to all of a particular Context/object in the system address. All nodes that contain Context 42, object 3 (outside temperature) will process the broadcast message.
6
This may change as more refinements are made to the Context documents.
185
CAL
Figure 7.15 Typical Context header information. This is the header and first object of the Audio Context (10).
The Audio context contains necessary objects for the majority of audio amplifier functions. The basic context usage assumes one or two channels, but additional objects are provided for four-channel and surround sound applications. Intended for use in A/V as well as nonA/V use (such as in intercoms, speakerphones, etc.).
7.14 illustrates an outside temperature sensor device. The temperature sensor device contains the Environmental Sensor Context (41), and uses the Outside Temperature object (03). This product is intended to bind to ALL Environmental Status Contexts (42) and Outside Temperature objects (03) in the home, reporting outside temperature to any product that needs or wants the information. When the Outside Temperature object in Context 41 sends a message reporting an outside temperature, it uses the house system address, Broadcast node address (0000), so that it will be received by all nodes in the house. The message containing the outside temperature is picked up by any node in the house containing the Environmental Status Context/Outside Temperature object, such as the living room television and the heat pump thermostat. Binding via the broadcast node address makes field installation of products an easy task.
Context Examples Appendix B contains two sample Context tables (Audio and Lighting). Each of the Context descriptions starts with a header that defines the name of the Context, and the Context class number (in hex), followed by a brief description of the general use of the Context (Figure 7.15). The Audio Context contains necessary objects for the majority of audio amplifier functions. The basic Context usage assumes one or two channels, but additional objects are provided for four-channel and surround sound applications. The Audio Context is intended for use in A/V as well as non-A/V use (such as in intercoms and speakerphones).
186
Chapter Seven The Context definition then lists all of the objects used in the Context. Objects are numbered sequentially starting at 01 for the Context Control object. Objects are referenced in a Context by number, not class.
The Universal Context Every CEBus node must contain the Universal Context (00). The Universal Context does not model any functional system of a product. Rather, it stores the global CEBus housekeeping information about the node in the Node Control object. The Universal Context may optionally contain a special function Data Memory object called an Event Manager. The Event Manager object can be used to download program code, CAL commands, or other data to the node over the network.7 The information in the Event Manager object is assumed to be manufacturer specific. Node Control Object The Node Control object (01) is the storage location for global device information such as the system and node address, the product serial number, and other information that applies to the entire product. IVs in the Node Control object are provided to facilitate product identification on the network, aid address configuration, and determine product capability. Figure 7.16 shows the contents of the node control object. Only the IVs in bold type are required. However, many of the IVs are designed to enhance interoperability and should be used if possible. A brief discussion of some of the key IVs follows. The optional power IV (w) is intended to control the “global” power to a device and is applicable only to products whose on/off function is not included as part of other contexts in the device. Typical products that might use the power IV are TVs, VCRs, and computers. The on_offline IV (l) can be implemented to allow a device to go offline for service or manual control. When on_offline (l 0), a node will only respond to a message to put the device back on-line (set the IV to 1) or resource allocation requests. The serial_# IV (s) contains a manufacturer-assigned product serial number. It should be 18 characters or less and contain any combination of ASCII characters. Knowing the serial number of a product allows unique identification of the node and is useful for device address configuration. 7
Use of the Event Manager object is very rare. It is primarily intended to enable controller devices to download executable code to a node over the CEBus network.
187
CAL
Figure 7.16 Node Control object used only in the Universal Context.
The CIC can assign a manufacturer a unique first five-character code to be used as the first five characters of a manufacturer-supplied serial number for all products built by that manufacturer. This insures that no two CEBus-compliant products will inadvertently have the same serial number. The product_class IV (c) is used for product-type identification. The IV contains a number indicating that the product belongs to a specific product category. The list of numbers is given as an appendix to the CAL specification. A portion of the list is provided below (numbers are decimal). 1
TV
50
Microwave
2
Video Monitor
51
Stovetop
3
VCR
52
Oven
4
Audio Recorder
53
Refrigerator
5
Amplifier
54
Freezer
188
Chapter Seven 6
Pre-Amp
55
Coffee Maker
7
Audio Processor
8
Audio Receiver
61
Light Switch
9
CD Player
62
Light Sensor
64
Wall Outlet
20
Temperature Sensor
21
Hygrometer
73
Computer
22
Damper
74
Printer
23
Thermostat
75
CD-ROM
77
Fax
30
Clock
31
Radio
80
Water Heater
32
Clothes Washer
82
Electric Meter
33
Clothes Dryer
83
Gas Meter
34
Dish Washer
84
Water Meter
35
Door
37
Shower
91
Motion Sensor
40
Toilet
92
Security Interface
Class numbers are designed to help locate products on the network. For example, to locate all the VCRs in the house, a message is sent to the broadcast node address to retrieve the specific node address of devices with product_class of 3: [00,01] if (‘c’ EQ 33h) getArray ‘a’ (getArray is a “method” [describing the action to be performed] to return an array of data from the IV)
Manufacturers are encouraged to implement product class IV because it is very useful for network configuration. The system_address (h) and unit_address (a) each hold a 16-bit binary address forming a 32-bit network address for the product. Prior to being installed, a product’s system and node address are unknown (usually set to zero). When installed, these addresses must be acquired. The group_address (g) optionally holds one or more 16-bit group addresses. The number of group addresses that a product can hold is up to the manufacturer, but a minimum of one is recommended. The storage allocation for the IV must be adequate to
189
CAL
hold the desired number of group addresses. The inherit and disinherit methods are used to add and remove group addresses from the IV. The capability_class IV (b) is a rough indicator of the CAL capability of the node. Currently, the IV is a number from 0 to 3 defining four classes. The number defines the minimum guaranteed capability, but the product may always do more. Class 0 devices support only the minimum object/IV/method requirements. Class 1 devices support all objects/methods/IVs that are explicitly identified in the Context specifications used. Class 2 devices support class 1 devices plus a minimum of two group addresses and all basic methods (excluding do, while, repeat, copyValue, and the like). Class 3 devices support class 2 devices plus all methods. The context_list IV (o) is a data array, set by the manufacturer, of all contexts used in the node. The context list uses the context ID syntax: context number followed by the context class (two bytes) for each context used. This IV can be read by the getArray method to determine what contexts are in the node. The configured, setup, user_feedback, and config_master IVs are used for address configuration; to allow the node to acquire a system and node address and, if implemented, allow address propagation to other nodes. The recommended procedure to acquire a system and node address and to propagate a system address to other nodes in the same house, is described in the section on address configuration in this chapter. The configured IV (f) indicates whether the device has acquired a valid system and node address. Prior to installation and configuration, the IV is FALSE. After configuration, the IV is set to TRUE by the node software. The setup IV (i) is used in the address configuration algorithm. It is set to 1 during installation and is incremented to ensure only one device is trying to configure the node. The user_feedback IV (u) is intended to provide, through an application interface, an indication to the user. The indication is primarily intended to assist in address configuration, but it can be used for other functions as well. Some user_feedback values have been preassigned to assist address configuration. 0 Off, no feedback. 1 Initiate an external indication for a specific length of time, such as blinking an LED for 30 seconds, so that the user can locate the
190
Chapter Seven device being configured. The IV value returns to zero following the indication. 2 Provide feedback that the configuration process completed successfully. 3 Provide feedback that the configuration process did not complete successfully. The config_master (t) is a boolean IV implemented only in devices that can acquire and propagate their system address. The IV is always FALSE unless the node has acquired the config_master resource. The source_unit_addr (d) and source_system_addr (e) hold the source node and system address of the last received message. The conformance_level (v) is a character string that indicates a version of CAL that the product is using. The present level of the released standard is 1.0. This value will only change if a significant change is made to the language to add additional capability. The authentication_keys (k) are used in the message authentication algorithm. They are only implemented if message authentication is required in the node. Finally, the reporting IVs can be used to report a change of condition such as power changing from on or off.
Context Control Object The Context Control object is found in every context. It contains only one read-only IV, the object_list (o). The IV is read with the getArray method to obtain a list of all the objects implemented in the context containing the Context Control object. The returned object list contains 2 bytes per object: the object class followed by the object number. For example, if a context contains three objects (number 1, the Context Control object (02); number 3, an Analog Control object (07); and number 6, another Analog Control object (07)), the data stored in the object_list is: 01 02 03 07 06 07
The Context Control object is object number 01 in all contexts except the Universal Context where it is number 02.8 8
This exception is due to the fact that the Context Control object was created after the Node Control object/Universal Context was used in early products.
191
CAL
Determining Product Capability CAL contains many “hooks” in the Context/object data structure to allow a node to determine the function and capability of any other node on the network. Information contained in the Node Control object and the Context Control objects can be used to build a complete profile of a product’s CAL capability. The IVs intended for this purpose include: Node Control object product_class—determines the general category of the node. capability_class—determines general CAL support. conformance_level—CAL version level. context_list—contains a list of all implemented contexts in the device. This is the primary indicator of what a node can do in terms of interoperability. Context Control object object_list—contains a list of all implemented objects in the context. This is the primary indicator of what each context is capable of doing. The context_list and object_list IVs are required; thus, it is always possible to tell what functions a product contains. This allows intelligent nodes (PCs, controllers) to present a user with a list of available functions. It also allows scenarios to be developed for more complex automation tasks in the home.
Where Do Contexts Come From? EIA-600 contains Context specifications for only four Contexts, which are called the General Contexts: Universal, Time, Data Channel, and User Interface. The Universal Context is required in every product: the other three are used across industry product groups. Other Context specifications are developed by the CEBus Industry Council (CIC) in industry-specific working groups. Context working groups exist for each major industry category, such as HVAC, Security, Lighting, Utilities, and so on. Each working group is made up of representatives from companies that have a business interest in the product category. The working group develops the Contexts. When completed, Contexts are reviewed by the Context Development Committee and
192
Chapter Seven submitted for ballot to all members of the CIC. Context specifications are available from the CIC by industry group.
Messages: Object Communications CAL messages are generated by objects via the CAL Interpreter or the object’s application code. Objects communicate with other objects by setting or reading their IVs. The message portion of the packet is formally known as the Application Layer Service Data Unit (ASDU). There are two types of ASDU: The command message and the response message. The command message is sent to a device to perform an action such as setting or reading the value of an IV. If a command message is sent that generates a return value (such as reading an IV), a response message is returned.
Command ASDUs The command message ASDU contains one or more CAL commands.9 The message syntax of a CAL command is shown in Figure 7.17. The message consists of a context ID, followed by an object number, followed by a method, optionally followed by an IV and one or more IV arguments. The byte value F5 is a DELIMITER token. Token names (reserved byte values used to parse the message) are given in uppercase.10 The example message in the syntax figure sets the channel of a tuner to 15. The context ID is 12 (the Tuner Context); the object number is 03 (the Channel object); the method is setValue (45 hex), which sets the IV to the value given as an argument; the IV is the current_value (43 hex); the F5 token separates the IV label from the argument; and the argument is the number 15 represented in ASCII. Because the current_value is a numeric data type, the argument is numeric, and numbers are transmitted as ASCII characters (remember?) 1, 5. Message Address The context ID object # pair forms the destination object address for the message. It identifies a particular object in 9
Refer to the CAL specification for the syntax for multicommand ASDUs. Because being able to parse an ASDU with more than one command is optional, it is seldom used.
10
Tokens are represented by single byte values in the range of hex values (E0 to FE).
193
CAL
Figure 7.17 Syntax of CAL message portion of packet. The example message is for the Tuning Context (12), Channel object (03), to set value (setValue 45) of the current_position IV (43) to 15.
FROM address
NPDU header
APDU header
CAL message
<method>[[<arguments>]] 12
03
45
43 F5
31 35
a particular context in the product. The context ID is made up of two parts. Its syntax is = []
The first part of the context ID is an optional context number. Each context in a product is numbered because there may be more than one instance of the same context class in a product. The number is only used if there is more than one context of the same class in the product. In the previous tuner example, the Context number is omitted. Context class values run from 00…9E hex. Context number values run from A0…DE hex. The context number DE is reserved to indicate the message should be applied to all contexts of the class in the device. For example, a context ID of DE 10 indicates that the message is addressed to all Audio Amplifier Contexts (Context class 10) in the device. Context class values 90…9E are reserved for custom Contexts. Manufacturers may create unique Contexts for a particular product by assigning the Context a class number in the range 90…9E. The object number is the sequential number of the object in the Context. The class of the object (except for a special case) is not used. Object numbers occupy the range 01…3E. A seldom-used construct of the object number is used to identify all objects of a particular class in a context. The construct is 00 object class (that is, 00 hex followed by the object class). This construct means that the message is addressed to all objects of the given class in the Context.
Response ASDUs A response ASDU is generated by a node whenever a node receives an explicit-invoke APDU, regardless of the command message. The returned
194
Chapter Seven response always uses the Result APDU (APDU type 010). The response may contain information returned to a node as the result of a command message. The general syntax for the response ASDU is <status token> []
The status token is a 1-byte indicator of the type of response, and the returned data is any data returned as a result of the command message. The status token is one of three values: COMPLETED (FE), FALSE (FC), or ERROR (FD). The COMPLETED token (FE) is returned if the last received command message was executed successfully, or a command with a boolean expression evaluated to true. If the method in the command message does not generate a returned value (such as a setON, or increment), only the COMPLETED token is returned. If the command message reads the value of an IV (using getValue, getArray, and the like), the returned value follows the COMPLETED token. If the command message contains an if, do, or while method followed by a boolean expression, the expression evaluation will always generate a response byte, in addition to any response generated as a result of the rest of the message. If the boolean expression evaluates true, a COMPLETED token will be returned. If the true evaluation also causes a message to be executed successfully, the response contains two COMPLETED tokens: one to indicate the boolean expression evaluated true, and another to indicate the message executed successfully. For example, assume that the current_value of an analog control object is a numeric data type and currently has the value 67. A command to read the IV is received (using explicit_invoke APDU service): getValue ‘C’
If the message is executed successfully, the response is: 36 37
or FE 36 37
However, if the command is: if (‘C’ 0) BEGIN getValue ‘C’ END
195
CAL then the returned response is: 36 37
or FE FE 36 37
The first FE indicates the boolean expression was true; the second FE indicates the getValue executed successfully. The FALSE token (FC) is returned if the received command message contains a boolean expression that evaluates to false and, therefore, the message is not executed. For example, if the following message were executed (given the same IV value of 67): if (‘C’ 0) BEGIN getValue ‘C’ END
the returned result would be just FC, indicating a false result from the boolean expression. The ERROR token (FD) is returned if the received command message is not executed by the CAL Interpreter. The ERROR token is always followed by an error code as the returned data . For example, if a command message is sent to a light switch, to the Lighting Context, Light Level Control object, to set the value of the units_of_measure IV to 13, the light switch will return the following response: FD 31 35
which is error 15 (IV is read-only). The error codes are listed in Appendix C.
Methods A method identifies an action to be performed by the CAL Interpreter on one or more IVs in an object. A method identifier is a single byte value (in the range 40 to 7E hex) that is followed by one or more arguments separated by the DELIMITER token. Each method operates on a specific IV data type. Method Table The following table lists all of the CAL methods in order of their hex value. Each entry contains the method name, the argument list, and the data types of the IV on which the method operates. This is followed by a brief description of the method operation.
196
Chapter Seven Methods whose ID is underlined, must be implemented if an object contains an IV on which the method can operate. The following symbols are used in the table: Data Types: Boolean, Numeric, Character, Data Method operates on this IV data type Method does not support this data type ❚ F5 delimiter Data types Hex METHOD
Operates on: ARGUMENTS
B
N
C
D
IV
40 nop No operation 41 setOFF
Sets a boolean IV to 0 (FALSE) 42 setON
IV
Sets a boolean IV to 1 (TRUE) 43 getValue
IV
Returns the contents of the IV in a response message 44 getArray
IV [❚ [offset ] [❚ count ]]
Returns count number of bytes of the data IV starting at the offset byte. The default offset is 0 (beginning of the data); the default count is all of the data. 45 setValue
IV [❚ value ]
Sets the IV to value . If no value is given, then the IV is set to the value of the object’s default_value IV. 46 setArray
IV ❚ [offset ] ❚ data
Stores data bytes into a data IV starting at an offset number of bytes. The default offset is 0 (beginning of the IV). 47 add
IV1 ❚ IV2 [❚ IV3]
If only IV1 and IV2 are given, then IV2 IV2 IV1. If IV3 is given, then IV3 IV1 IV2. 48 increment
IV [❚ number ]
Increments IV by number . If number omitted, IV increments by step size IV.
197
CAL Data types Hex
Operates on:
METHOD
ARGUMENTS
B
N
C
D
49 subtract
IV1 ❚ IV2 [❚ IV3]
If only IV1 and IV2 are given, then IV2 IV2 IV1. If IV3 is given, then IV3 IV2 IV1. 4A decrement
IV [❚ number ]
Decrements IV by number . If number is omitted, then IV decrements by step size IV. 4B compare
IV ❚ argument
Used to compare the magnitude of IV with argument . argument can be an IV label or a value. The data type of IV and argument must be the same. Returns 1 (31 hex) if IVGT argument , 2 if IV LT argument , or 3 if IV EQ argument . 4E swap
IV1 ❚ IV2
Exchanges the contents of IV1 and IV2. Data types of both arguments must be the same. 4F report
IV
Initiates a reporting message from an object regardless of any predefined reporting_condition in the object. The value reported is IV. The reporting IVs must be set up correctly. 52 exit
[value ]
Ends the current level of execution. If used within a loop (do, while, repeat), the loop is terminated and execution continues after the END token. If value is given, all parsing terminates and value is returned in a response packet. 53 alias
alias ID [string ]
Used to equate a commonly used character string to a 1-byte alias ID. alias ID must be in the range 80 to CE. If no string , then the alias ID is canceled. 54 inherit
IV ❚ value
Used to assign a value to a resource IV (system address, node address, group address, data channel number). The CAL Interpreter must hail for the resource (except for the group address). 55 disinherit
IV [❚ value ]
Used to disinherit a value from a resource IV. IV must be the group address IV or a data channel IV. value is a group address or data channel number that has previously been inherited. 56 if
boolean-expr BEGIN message list [ELSE message list ] END
198
Chapter Seven Data types Hex METHOD
Operates on: ARGUMENTS
B
N
C
D
Used for the conditional execution of message list based on the result of booleanexpr . message list can contain any message that is valid for the object. booleanexpr may contain any IV that is used in the object. 57 do
boolean-expr BEGIN message list END
Used to perform a do-while—style loop. One execution of message list will occur prior to testing boolean-expr . Execution of message list will terminate when boolean-expr evaluates false. 58 while
boolean-expr BEGIN message list END
Used to perform a while-do—style loop. boolean-expr is tested prior to executing message list . Execution of messages will terminate when boolean-expr evaluates false. 59 repeat
value BEGIN message list END
Will repeat the execution of messages for value number of times. 5A build
macro ID BEGIN message list END
Used to create a macro identifier for one or more messages frequently sent to an object. macro ID must be in the range 80 to CE. 5B copyValue
argument ❚ IV [❚ context ID object # ]
Allows copying an IV from one object to another object in the same product. Copies argument to IV in the same object or in context ID object # in the product. argument is usually an IV in the object receiving this method but can be a value.
Required and Optional Methods A product need not be able to parse and execute all methods. The methods in the previous table whose ID is underlined must be implemented if an object used in the product contains an IV on which the method can operate. The following rules must be followed. If an implemented object contains a boolean IV, then the interpreter must be able to execute the setON, setOFF, setValue, and getValue methods on that IV. If an implemented object contains a numeric or string IV, then the interpreter must be able to execute the getValue and setValue method on that IV. If the object contains a data IV, the interpreter must be able to execute the setArray and getArray method on that IV.
199
CAL
If an object contains an IV that is a CEBus resource (address, data channel), the interpreter must be able to execute the inherit, disinherit, and if methods on the IV, in addition to whatever other method is appropriate for the IV data type. In practice, almost all operations required of objects can be performed by using the basic set of required methods (setOFF, setON, getValue, setValue, getArray, setArray, if, and inherit/disinherit). If a method is used on an object and it is not supported, an error response (unknown method) is returned. Macros A message may contain a macro identifier instead of a method. A macro identifier is a 1-byte value in the range 80…CE hex that takes the place of a method. A macro means the same in CAL as in most programming environments; it identifies a predetermined action or group of actions performed in place of using or sending a list of those actions. In CAL, a macro defines a predetermined set of messages to be performed on or by the receiving object. Macros are defined in the CAL specification for some very common operations and are additionally defined in some context documents. In each case, the macro performs an operation that is so common that defining a macro identifier makes sense. Like a method, a macro identifier may take an argument. The best example of the use of a macro argument is in the address configuration algorithms described later in this chapter.
Message Generation Binding implies a message exchange between the bound objects. Objects originate messages to other objects in one of two ways: the object’s associated application code generates a message, or the object’s reporting condition IVs cause the CAL Interpreter to generate a message automatically (Figure 7.18). The former is called an application message: the latter is called a reporting message. Reporting Message Generation The reporting message capability of CAL is the most common way to accomplish object binding. Whenever the value of the desired IV changes in a predetermined way (increases, decreases, becomes true, and so on), the CAL Interpreter sends a message to another device (or group of devices) to update the value of a “target” IV at a Context/object address. The advantage of using reporting is that it can be preprogrammed in network output objects because the destination Context/object is
200
Chapter Seven
Figure 7.18 Messages originate from the CAL Interpreter using the reporting IVs or an object, or from the object’s application code.
usually already known. It can also be easily programmed in the field, so binding relationships can be established when products are installed. Reporting uses a set of predefined IVs available in all network output and network input/output objects: report_condition, report_header, report_address, and previous_value. These IVs are usually at the end of an object IV list. They are used as a group by the CAL Interpreter to determine when and where to send a message to another node. Their function is illustrated in Figure 7.19. Report_condition: A data variable containing a boolean expression describing a condition in the object to test to determine whether a report message should be sent. The expression uses standard CAL boolean expression syntax. Report_address: A data variable containing the node and system address of the destination device. Report_header: A data variable containing the CAL message to send to the destination device (less the current_value argument). The message contains the Context, object, method, and IV. The IV argument is appended from the current_value of the object. Previous_value: The value of the current_value when the last message was generated. It is the same data type as current_value. Used by the CAL interpreter to compare against the present value of current_value. The CAL interpreter automatically updates it whenever a report is sent. For an object to generate a report, the report_condition, report_address, and report_header must be set to valid values by manually coding them or sending messages to the object to set the IVs.
201
CAL
Figure 7.19 Use of the reporting IVs in network output objects. Reporting generates a message to the report_address. The message is contained in the report_header with the current_value appended.
Whenever report_condition evaluates true, the message in the report_header (with the object’s current_value appended) is sent to the address in report_address to update the value of a “target” IV. The report_header contains the target Context/object address. Using the Report_condition IV The report_condition IV is used by the CAL interpreter to determine whether a report message should be sent. If report_condition contains a valid CAL boolean expression of the form: [AND/OR/XOR ]
the CAL Interpreter will test the boolean expression on a regular basis.11 If it evaluates false, nothing happens. Whenever the expression evaluation transitions from false to true, the Interpreter performs two tasks: 11
Testing is done as often as possible when the Interpreter is not processing an incoming or outgoing message. The frequency depends on the application needs.
202
Chapter Seven 1. It generates a message using the report_header and report_address IV to form the message (Figure 7.19). 2. It replaces the previous_value IV with the value of the current_value IV. CAL appends the current_value IV to the report_header and sends the message to the report_address. A report will not be generated again until the expression evaluates from false to true (that is, it must first transition from true to false and then false to true). The form of the relational expression is: (IV or ) GT/GTE/LT/LTE/EQ/NEQ/DELTA (IV or )
The IV(s) used in the relational expression must be in the object containing the expression, and the value must be the same data type as the IV type. The boolean expression always evaluates to true or false. The implemented length of the report_condition IV must hold the largest boolean expression anticipated. Typical examples of reporting condition expressions are: ‘C’ GT 34 (43 E4 33 34) ‘s’ EQ “00347A” (73 E8 EC 30 30 33 34 37 41) ‘C’ GT 150 OR ‘C’ LT 95 (43 E4 31 35 30 E1 43 E6 39 35)
String values are preceded by the LITERAL token (the EC in the second example) so they will not be parsed as an IV label. The DELTA operator evaluates as “changed by” and tests whether an IV has changed by a value amount. The test is performed by comparing the IV used in the expression to the previous_value IV. For example, the expression: ‘C’ 25
is evaluated as: ABS(‘C’ - previous_value) > 25
To test an IV for ANY change since the last report, the comparison value of 0 (zero) is used. For example, ‘C’ 0
tests C for any change since the last report. This will cause the CAL Interpreter to generate a new report message any time the value of ‘C’ changes. This is a very common expression.
203
CAL
Because reporting messages originate in the CAL Interpreter, the Interpreter usually uses implicit_invoke APDU service as a reply is not expected. The report message NPDU is usually set to all media, directory routing. The NPDU and DLPDU services are chosen by the implementer. There are no required protocol services for message reporting. Using the Report_header IV message header in the form:
