Power Over Ethernet Interoperability Guide

Power Over Ethernet Interoperability Guide

by Sanjaya Maniktala
Power Over Ethernet Interoperability Guide

Power Over Ethernet Interoperability Guide

by Sanjaya Maniktala

eBook

$110.99  $147.60 Save 25% Current price is $110.99, Original price is $147.6. You Save 25%.

Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
WANT A NOOK?  Explore Now

Related collections and offers


Overview

A Complete Guide to Transmitting Electrical Power and Data over Ethernet Cables

Power over Ethernet Interoperability explains how to safely transmit DC power over an existing data network cabling structure so that separate AC electrical wiring is not needed to power up devices connected to the network. With a focus on cost-effective unshielded twisted pair (UTP) cables, this book provides proven methods for designing reliable Power over Ethernet (PoE) equipment and ensuring that it functions effectively. Details on the IEEE 802.3af/at standards and how various devices can operate from PoE are also contained in this practical resource.

Coverage includes:

  • The evolution of PoE
  • Overview of PoE implementations
  • Detection
  • Classification
  • Inrush and power-up
  • Operation
  • Maintain power and disconnect
  • PoE state-machine diagrams
  • Magnetics
  • Isolation, PCB design, and safety
  • Surge testing and protection
  • Lab skills, thermal management, and decoupling
  • N-pair power delivery systems
  • Auxiliary power and flyback design

Product Details

ISBN-13: 9780071798266
Publisher: McGraw Hill LLC
Publication date: 02/15/2013
Sold by: Barnes & Noble
Format: eBook
Pages: 480
File size: 13 MB
Note: This product may take a few minutes to download.

About the Author

Sanjaya Maniktala is a Systems and Product Architecture Engineer with Freescale Semiconductor. He holds two patents in power supply technology and has written numerous articles on power supply design, appearing in such magazines as Power Electronics Technology, EDN, Electronic Engineering, and Planet Analog. He lives in Gilbert, Arizona.

Read an Excerpt

Power Over Ethernet Interoperability Guide


By Sanjaya Maniktala

McGraw-Hill Companies, Inc.

Copyright © 2013 The McGraw-Hill Companies, Inc.
All right reserved.

ISBN: 978-0-07-179825-9


Chapter One

The Evolution of Power over Ethernet

PART 1 AN OVERVIEW OF ETHERNET

Introduction

We seem to be in one of those rare moments in our history when absence has paradoxically emerged as the strongest proof of omnipresence. Since its rather humble beginnings back in 1973, Ethernet has metamorphosed so dramatically, it bears almost no resemblance today to its origins. As testimony to its ever-increasing popularity, 95 percent of all local area networks (LANs) in existence today are estimated to be Ethernet-based. But the irony is Ethernet may likely never have been around in its current form had it not been conceived way back then in its now-extinct form.

The basic purpose of Ethernet remains unchanged—to connect computers, printers, servers, and so on in LANs so they can exchange information and services among themselves. Although Ethernet continues to be a packet-based computer-networking technology, even its packets of data ("frames") are no longer exactly as originally envisaged. So much has changed in Ethernet that some very notable people have gone as far as to say Ethernet is (now just) a business model.

But first, to dispel a popular notion in a timely manner: Ethernet is not the Internet and vice versa (despite sounding similar). Internet actually came into our lives a bit after Ethernet did—specifically in 1989 when the first commercial Internet service provider (ISP), aptly named "The World" offered its services to the general public. Internet is, quite literally, an inter-network, a global network of networks. By now, most of the networks linked by the Internet do happen to be Ethernet-based, and nearly all Internet traffic starts or ends on an Ethernet connection. So it is obvious that a good part of the reason for the explosive growth of Ethernet is that it so naturally complemented the exponential growth of the Internet over the last few decades.

More recently, another very similar symbiotic growth pattern has quietly emerged from the shadows, perhaps a bit unnoticed. Riding on the remarkable growth story of Ethernet, figuratively and literally, Power over Ethernet (PoE) is now seeing a huge upswing of its own and seems to be now driving growth by itself. New families of PoE-capable network appliances and Ethernet equipment have suddenly started appearing. An ever-increasing percentage of "ports shipped" today are PoE-enabled, and PoE seems to be fast-becoming a default choice for Ethernet ports. It is therefore increasingly important for us to recognize PoE for what it is—a very fast-emerging technology. We should try and understand it much better before it gets ahead of us.

From the viewpoint of chip and systems designers, some rather unusual challenges are associated with implementing PoE. At a higher level, PoE represents the cusp of two major, hitherto parallel worlds of electronics development: power and networking. PoE is, in ways, the virtual confluence of the Applied Power Electronics Conference, (APEC) and Interop® (the annual networking expo at Vegas). It symbolizes the convergence of digital and analog hardware and software, power and data, and so on. It is exciting—and therein lie the challenges too.

If we look around, we may notice that things are not going so well on the human plane. Hardware personnel are still quite prone to ignoring software personnel; analog designers often shun digital designers, and so on—and vice versa of course. In the oft-repeated (though infamous) words of a famous analog legend of Silicon Valley, the late Bob Widlar: "Any idiot can count up to 1." No surprise that if we look around, we may notice several mutually suspicious "knowledge cliques" hovering around us. Unfortunately, skill segregation (specialization) is not commensurate with our modern world of increasing convergences. Personally, as systems and chip designers, we just cannot afford to allow our skill sets to become so increasingly finely tuned and subdivided anymore.

We need to illustrate this issue a little better, lest it sound hyperbolic to some. In 2006, one such engineer, let's just call him Bob for now (another Bob), recalled an ancient bench struggle he had faced decades ago. These are his words [italics added by the author of this book]:

I designed this thing. It took me forever, a good portion of a year. I finally had it, and I got it working with my test programs. It would work, but it only worked for 15 minutes and then it would go "bah," and all the lights would go in the wrong direction and then it would die. Then I would reboot, and then it would run again. I had these extensive diagnostics, random patterns, and everything, to just test the hell out of the thing, different word lengths, test every edge case. Then it would run just fine, over and over again through every—and then it would just die. I worked on it for a month and I couldn't figure it out ... I went down to the other end.... Tom looked at it, and he asked me a few questions, and then he said, 'Well, I know what's wrong.... you don't have any bypass capacitors on it. Now I know you just took a bunch of courses in digital electronics but at some point everything is analog. So what's happening, Bob, is when certain patterns get into your registers and they all go 1, and all the transistors turn on, they take too much current, too many electrons, and then the voltages start to droop because you've sucked in all those electrons and then all the digital devices start to malfunction. So what you need to do, Bob, is sprinkle some bypass capacitors here and there to store up some extra charge for those cases when you have lots of 1's in your registers.'.... I went quickly back to the lab and got my soldering iron, and I soldered on—I probably put a bypass capacitor on every third socket to this huge board. And I plugged the sucker in and she worked for the next 13 years. Anyway, I learned a lesson there—the analog digital—which came in handy later because Ethernet is a combination of analog and digital itself.

Now add to the anecdote two not-so-obvious facts:

1. PoE had not even come into the picture at the time of my bench-wrestling story, and the design "gotchas" were already appearing fast on the horizon.

2. The engineer in question was none other than Robert ("Bob") Metcalfe, considered today to be the "inventor of Ethernet."

So, we can imagine, that if Metcalfe was confused, more so without PoE on the scene yet, what we may experience today. That thought is humbling. Therefore, one of the key objectives of this book is to try and narrow down the differences between power and networking and analog and digital, and so on. Because if we don't, we may take almost forever to get to a successful, commercial product down the road (cable in this case).

One last question before we move ahead: Who invented Power over Ethernet (PoE)? Was it Bob? Or John? Was it Harry? Why not Jane? Actually, none of these. The correct answer lies buried somewhere in the 19th century—J. J. Carty was his name. And that is a true eye-opener, especially to some gung-ho "modern-day" engineers. In fact, it's actually over a hundred years ago that the basic principles underlying PoE started to take shape. So, in that sense, Ethernet actually came after PoE. It's funny how the world goes round and round. If not, it would probably all go "bah," in the words of Metcalfe.

And so, for just a moment longer, let's return to the future—that is, back to Ethernet.

A Brief History of Ethernet

Ether Network, Ether Net, EtherNet, Xerox Wire, X-wire ... That's what modern Ethernet almost got called. And had it, very likely it could have ended up in our collective memories (and Wikipedia) today as the "the now-defunct proprietary networking technology from Xerox Corporation." In fact, even the term "Ethernet" was originally a registered trademark of Xerox Corp. Fortunately for all of us, and perhaps even for Xerox, Xerox got talked out of all its rights on this subject by Robert Metcalfe himself and agreed to work with Digital Equipment Corporation (DEC) and Intel to spread its version of networking technology far and wide. Shortly thereafter in 1979 Metcalfe founded 3-Com Corp (last acquired by Hewlett Packard in 2010) but continued to work with the consortium, informally called DIX (for DEC, Intel, and Xerox). Together, they published the first formal (industry) Ethernet standard, DIX V1.0 in 1980. Meanwhile, the Institute of Electrical and Electronic Engineers (IEEE), in an effort to standardize LAN, had their very first meeting on this subject early the same year (1980). Because of the timing, some say that the well-known modern Ethernet standard 802.3 got it basic name—802 coming from February '80 or 2/80. Others say 802 just happened to be the next-available number in the normal sequence of IEEE standards. Either way, DIX approached IEEE to help standardize (their version of) Ethernet. But things were just as they are on any typical day at IEEE even today. In walked pushy General Motors with a rival LAN proposal called the Token Bus. Not to be outdone, IBM walked in with their Token Ring. As a result, IEEE bowed and decided to standardize all three proposed LAN standards. And that is how the IEEE "dot committees" got created: 802.3 was Ethernet, 802.4 was Token Bus, and 802.5 was Token Ring. These were all later blessed for international acceptance by the International Standards Organization (ISO), and became, respectively, ISO 8802-3, 8802-4, and 8802-5. Yet despite the initial boost, the latter two eventually died from "natural causes," though Token Ring does seem to have hung on rather stubbornly—for close to 15 years as per Metcalfe's estimate. Some think it is still around somewhere. But no one contests the fact that, in contrast, Ethernet grew extremely rapidly.

So, why did Token Ring in particular, lose out to Ethernet? One reason was that IBM was charging prospective vendors heavily in terms of royalties for producing Token Ring cards and medium attachment units (MAUs), or simply, the cable-driver electronics (akin to transceiver or PHY in modern lingo) placed between the controller card and the cable. This made Token Ring equipment too expensive overall. A Token Ring card itself could cost 5 and 6 times as much as an Ethernet card. Add to that more expensive cabling, and Token Ring literally priced itself out of the market.

Besides cost, a big advantage of Ethernet, going forward, was its inherent flexibility. On December 21, 1976, in an internal memo at Xerox, Metcalfe explained a key advantage of Ethernet in the following words (italics inserted here belong to the author of this book):

The OIS [Office Information Systems] protocol is based on distributed many-to-many communication as required by incrementally grown and increasingly interconnected office systems, rather than hierarchical mainframe-centered data processing systems.

The way Metcalfe originally visualized Ethernet was a single long coaxial cable connecting many computers (workstations) and printers. In modern terms, this is a "bus topology." A new device (computer, printer, and so on) could be simply added on, as the need arose, using a "vampire tap." This contained a needle (let's call it a Dracula tooth to be visually clear and consistent) that would get clamped down and penetrate the coaxial cable to make contact with its inner conductor, while the outer shield of the cable would connect to the outer shield of the newly added segment. So the network could be built up steadily over time, rather than needing a big central infrastructure right off the bat (preguessing future needs). This proposed type of LAN architecture was envisaged to grow along with the size of the organization.

The bus topology is somewhat akin to a giant plumbing system with a main water pipe ... (but with data, not water) flowing down, with several feeder connections on it along the way (see the hybrid architecture example in Fig. 1.1).

It is indeed ironic that in later years, the basic framework of Ethernet (in terms of its packet-based architecture and supporting techniques) proved flexible enough to allow moving away from the original bus topology concept to a "star topology." In this new architecture, every computer (or networking device) gets connected via a dedicated cable plugged into a central switch or hub. In terms of hardware expandability, the star topology is not as flexible as the bus topology, but it can provide much higher speeds, besides other advantages. As PoE designers, we should also realize that the bus topology could never have supported PoE as it is today. The star topology is a prerequisite for power over data cables, one cable for each end-device. So clearly, things seem to have gone in the right direction, both for data and power. That's survival of the fittest.

Another reason for the continuing rise of Ethernet was that Ethernet got suddenly empowered along the way by something called a "switch." This concept seems to have originally come out of a startup called Kalpana (Hindi for imagination or vision), cofounded by Vinod Bhardwaj, an entrepreneur of Indian origin. Kalpana was acquired by Cisco in 1994, ten years after Cisco itself was born. The switch eliminated a very basic problem of collisions, which was slowing down networking in general. The switch eventually helped achieve much higher data rates. It soon became unstoppable because it catered to the rapidly growing need for speed.

What are collisions? Quite similar to what you would expect would happen if hundreds of cars were let loose in both directions on a single lane. More formally expressed, collisions can be explained as follows: (Data) collisions occur when, for example, all the computers on a shared line start "talking" (transmitting data packets) simultaneously. What results is almost noise (garbage). It is also very similar to a whole bunch of people brought into a small room, each person trying to talk over everyone else's head to someone else in the room. Pretty soon, with all the din and shouting, no one really understands a thing anymore. We have all been there and perhaps done that too. To avoid this unpleasant and inefficient situation, the connected computers need to detect that a collision is occurring, then back off and try a little later again. In doing so, they must not try simultaneously again, or a clash will recur, slowing down all communication for an even longer time. On the other hand, if they wait too long before trying once again, the communication slows down again. But if they try too fast again, they run the risk of overlapping (talking simultaneously), causing more delays. And so on. That is where Metcalfe originally came into the picture. His claim to fame is U.S. patent number 4,063,220, titled "Multipoint Data Communication System with Collision Detection." This is basically a (statistical) algorithm to back off and try again in an optimum manner. In contrast, and in a more deterministic manner, IBM's LAN architecture had a software "token" that was moved around in a circle of connected computers, and so whoever had possession of the token at a given moment, got the right to transmit. It was a little like the game of "passing the parcel" at a typical children's birthday party. Token Ring did seem to be superior to Ethernet initially, especially to engineers who felt uncomfortable with the lack of clearly defined timings characteristic of Metcalfe's software-based algorithm.

Note that in 1985, IEEE finally published a portion of the ongoing standard pertaining to Ethernet: IEEE 802.3 titled "Carrier Sense Multiple Access with Collision Detection ('CSMA/CD') Access Method and Physical Layer Specifications." We can see the title does not even mention the word "Ethernet." But Metcalfe's original term did catch on in a big way. And so the IEEE 802.3 standard was, and still is, referred to as the Ethernet standard.

CSMA/CD can be explained in informal language as follows:

1. CS: Carrier Sense (Hey, do I hear someone talking?)

2. MA: Multiple Access (Careful, we can all hear what each one of us is saying!)

3. CD: Collision Detection (Hey, we're both talking now—stop!)

The underlying logic of CSMA/CD is

1. If the medium is idle, transmit anytime.

2. If the medium is busy, wait and then transmit right after.

3. If a collision occurs, send 4 bytes of "jam" signal to inform everyone on the bus, then back off for a random period, and after that, go back to Step 1 above.

The last point is pretty much the social technique we use rather intuitively, in a normal, polite group or conversation, say at a dinner party in the evening, as opposed to trying to talk, or rather shout, at each other in a crowded bar (perhaps with 100 dB of rock music playing in the background).

(Continues...)



Excerpted from Power Over Ethernet Interoperability Guide by Sanjaya Maniktala Copyright © 2013 by The McGraw-Hill Companies, Inc.. Excerpted by permission of McGraw-Hill Companies, Inc.. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Table of Contents

Contents

From the B&N Reads Blog

Customer Reviews