| Home
Toys Article - February 2000 - [HTI Home Page] |
KEEP INFORMED OF THE LATEST NEWS Sign Up for our Newsletter [Click Message To Learn More] |
|
POWERLINE
COMMUNICATIONS - A PUBLIC RESOURCE
Multiple protocol support is a requirement and a well-designed PLC technology transports multiple protocols within one PL network, enables applications to use more than one protocol, and identifies the protocol in use. |
The PLC-1 transceiver is a digital Integrated Circuit (IC) implementing a half-duplex transmitter/receiver function for Power Line Communications (PLC). The IC includes a complete set of high-level functions, enabling designers to easily implement high-performance PLC networks. |
Multiple
dwellings share a given PL network and potentially use different, incompatible
PLC systems. A well-designed PLC technology tolerates the presence of foreign
PLC technologies on the network.
A significant fact sets PLC apart from similar purpose technologies: the PLC medium, i.e., the power line (PL) itself, is a public resource. In North America, a given number of dwellings (typically less than twenty) share one power transformer (e.g., a 14.4 kV-to-120/240 V pole-mounted transformer that supplies neighbouring dwellings). Note that high-frequency PLC signals are attenuated as they cross these power transformers.
|
PLC technologies exist in different, incompatible forms presenting different modulation characteristics, using different frequencies, employing dissimilar Medium Access Control (MAC) logic, etc. These technologies cannot assemble data packets from foreign PLC transmitters. Considering the public and shared aspects of the PL medium, what happens when your neighbour uses a different (foreign) PLC technology within his or her dwelling? The consequences depend on the PLC technology itself.
Because they "listen" to a large frequency spectrum, swept carrier technologies that do not implement a real Spread Spectrum (SS)* system are, from inception, more sensitive to the presence on the PL network of a foreign PLC system. The foreign PLC technology, when using the medium to transmit data, may impede upon wideband, swept carrier, non-SS systems, though this interference remains dependent on Signal to Noise ratio (S/N, where S is the Signal of the swept carrier system and N is the Noise, i.e. in this case, the signal level of the other, foreign PLC system).
|
* Note: true, well thought-out
spread-spectrum systems specify a negative number for their signal to
noise ratio (S/N), for example, minus fifteen decibel, i.e., -15 dB.
Wideband technologies that specify a positive S/N, for example 3 dB, are
not likely to be true spread-spectrum systems because their S/N
figure does not show the processing gain normally associated with the
spread spectrum technique. These systems are simple swept carrier
systems.
|
Let us imagine a given setup where both your wideband, swept carrier, non-SS system presents substantial signal attenuation (your receiver is far from the transmitter, heavy loads are connected along the communication path, etc.) and a foreign signal is emitted close (less attenuated) to your receiver. In such a situation, your given wideband system will likely be impeded upon. This would not be the case, i.e., your given wideband system should operate normally if, say, the signal from the foreign technology was highly attenuated. Indeed, problems to wideband, swept carrier, non-SS systems are unlikely in single-family dwelling installations where the long runs of power wiring connecting several neighbouring dwellings present relatively high impedance paths. However, this is not the case in many apartment buildings where the fuse (breaker) panels of two given dwellings are sometimes very close to one another; in this case, wideband, swept carrier, non-SS system operation will likely suffer from interfering foreign signals.
In the context of PLC technologies, narrowband systems present an advantage over wideband systems since narrowband systems "listen" to only a small portion of the spectrum and thus filter out all the other undesired frequencies. Well-designed narrowband systems tolerate swept carrier signals: on a given PL, narrowband systems "see" wideband signals coming from a swept carrier technology as small amplitude noise. Indeed, the wideband technology spreads its signal over a large frequency spectrum so only a small amount of energy is ever received at any given narrowband frequency. Although noise or foreign PLC signals at the frequency of a given narrowband system could impede upon its operation, narrowband systems coexist with other narrowband systems that use a different frequency. Wideband, non-SS systems cannot coexist with any foreign narrowband signal in (or close to) their large operating band. The bottom line is that when either noise or a foreign narrowband signal impedes upon a given narrowband system, that same noise or foreign signal will surely impede upon any wideband, non-SS systems.
In North America, typical wideband systems available use a 100 to 400 (or 450) kHz frequency sweep. Available narrowband systems, on the other hand, use 120 kHz, 132.5 kHz, or some other discrete frequency and most narrowband systems are in the 100 to 500 kHz band (the PLC-1 frequency, for example, is programmable but typically operates at 262 kHz or 450 kHz). The consequence is that currently available narrowband systems might impede upon existing swept carrier, non-SS systems when sharing a given PL. Narrowband systems, on the other hand, will probably tolerate typical 100 to 400 (or 450) kHz sweeps, as well as other foreign narrowband signals emitted at distant frequencies.
The 120 kHz and 132.5 kHz frequencies mentioned before are quite close; different systems operating at these frequencies may meet with some difficulties on common PL networks, unless they both operate at very narrow bands. The 262 kHz frequency used by the PLC-1 chip was carefully chosen for its propensity to allow harmonious coexistence with other current North-American PLC technologies. The PLC-1 tolerates the presence, on a given PL network, of other currently available PLC technologies, but the reverse is not true.
A common setup consists of different dwellings connected to a common power transformer and sharing a power line (PL) network. Several of these dwellings may use Power Line Communication (PLC) technologies that will sometimes have problems sharing the PL amongst themselves. What would happen if all the dwellings on a common PL network were to use the same PLC technology, i.e., share the same modulation technique, the same bit representation, or, as experts would say, the same physical layer? Would this setup resolve any and all problems or is not some higher-level compatibility also required?
Suppose that dwelling "A" transmits a packet that finds its way to dwelling "B". Since the physical layers of both systems are identical, B is able to assemble the packet bits received from A into a consistent message. If, however, A formats and interprets its packets differently than does B, because they use different protocols**, B could erroneously interpret any or even all the packets coming from A. For example, a packet intended to turn off a given load in dwelling A could be read by B as "start the sprinkler." A hasty conclusion might come to mind: "Since they could eventually meet on a shared PL network, physical-layer compatible PLC technologies must use a unique protocol." Is this conclusion correct?
|
** Protocol (OSI definition) :
"(N)-protocol : A set of rules and formats (semantic and syntactic)
which determines the communication behavior of (N)-entities in the
performance of (N)-functions."
|
Existing PLC technologies, like almost all communication technologies, implement a single protocol. We at Metricom Corporation propose that the PLC market requires a system that implements more than only one protocol, even within a single PL network. We push our proposal further and state that even within a single dwelling, there is a need for more than one protocol, because no single protocol has ever been able to fulfill the requirements of all applications, simple or complex, current or forthcoming. The record for communications technologies shows us that an Ultimate, Universal, and Definitive protocol has never existed and probably never will: literally hundreds of protocols and communication standards exist, many of which have either already disappeared from the market or are about to, and many other new protocols and communication standards will be created in the future.
Let us look at the simple example of a PLC relay that only requires interpretation of the ON and OFF commands. Now, the local power utility shares the PL medium and might want to encrypt the messages to protect sensitive data. Notice here that the PLC relay and the electric meter share the same PL in a single dwelling. Should the PLC relay interpret the complex power-utility packets? This would imply dramatic cost increases for the PLC relay application!
Consider a second example. Some years ago, dwelling A installed a nice PLC lighting-control system produced by Manufacturer XY, using the reliable XY modem, and implementing the XY protocol. This system was state-of-the-art when it was designed, but as technology continuously evolved, new protocols appeared and today, a hypothetical protocol named "BUZ" enables home control through a satellite, via the Super-Internet, etc.
So what happens when dwelling B installs a new system, also produced by Manufacturer XY, using the excellent, time proven XY modem, but implementing the new, powerful BUZ protocol? We now have a single pair of wires (the power line shared by both dwellings) connecting two systems using the same XY modems, but implementing different protocols. What happens to the lighting system in dwelling A when it reads a BUZ packet coming from dwelling B? Will lights begin turning on and off randomly? Note that similar problems would occur if dwelling A, that owns the older lighting-control devices, were to update its system with new products using the BUZ protocol.
Most, if not all, current PLC technologies are single-protocol and suffer from this important shortcoming. By assuming that the protocol they propose at this time will be the Ultimate, Universal, and Definitive protocol, able to fulfill the requirements of any future application, for the lifetime of the PLC hardware, these single protocol systems will be unable to evolve over time. This problem must not be overlooked! Since, back to our example, dwelling A installed the XY modem, it is condemned for the next decade or two to use a single protocol; no product updates are possible and system evolution is dramatically stifled.
PLC-1 is protocol-neutral, i.e., it is a technology designed to support any current or future protocol required for any current or future application. PLC-1 simply identifies the protocol in use at the beginning of each packet. In our last example, the PLC-1 system would have identified its packets as "lighting control packets" (LGT) and the other ones as BUZ packets. When a PLC-1 lighting-control node receives a foreign packet, such as one labeled "BUZ", it simply rejects it as unknown, just as a PLC-1 relay will ignore a packet encoded by a power utility, for example.
Contrary to the Metricom PLC-1 system, conventional PLC systems do not identify their packets. Say that all dwellings on a given PL network use a hypothetical XY modem renowned for its particular reliability. The installation in one given dwelling of a PLC system that does not identify its packets condemns all the other dwellings on the PL network to use that single protocol for the life of the product. With the knowledge that protocols have consistently shown limited lifetimes, single protocol systems will likely become obsolete within a few years. However, multi-protocol systems like the PLC-1 live on and develop over time.
In the latest example, the lighting-control manufacturer could have identified packets as, say, LGT packets. A few years down the road, the manufacturer will be able to develop a new product integrating both the BUZ and the LGT packets and offer customers the opportunity to update their systems without superseding the old lighting-control nodes. The Metricom PLC-1 system is probably the only current PL technology to offer such a simple, yet efficient, characteristic...up until now, that is.
|
PRIVACY MUST BE PRESERVED |
We have examined examples of how multiple dwellings share a common PL. Moreover, a packet transmitted from a given dwelling A can (but will not always) be received in neighbouring dwellings. This potentially makes Inter-Dwelling Communications (IDC) intermittent (see www.metricom-corp.com , under "PL as a Public Resource", Page 1) and it is thus not advisable to implement any form of IDC. Although, with some specific installations, IDC could work well, it could cease working in other setups over minute-by-minute changing PL conditions or could even stop functioning altogether. Some PLC technologies and/or specifications assume that IDC will always work, regardless of the context and may use, for example, a hailing method to verify the status of neighbourhood PLC systems. Such methods may prove unreliable and may not work at all in field operations. Similarly, technologies that implement a token-pass algorithm to manage Medium Access could encounter problems when two or more dwellings share a common PL network.
We at Metricom Corporation consider that Inter-Dwelling Communications must never be used, allowing for the exception of specific installations proven by field tests to operate successfully in a multiple-dwelling context, and when neighbouring customers agree to share some common information. In all other instances:
|
PLC systems should never implement functions that set variables in neighbouring systems, change the state of neighbouring systems, or-even-query the status or variable contents of neighbouring systems. |
We have seen that PL is a public resource shared by multiple users that may potentially install different PLC systems. Two important points come out of this discussion:
- Well-designed PLC technologies tolerate different PLC technologies on a PL network, where "different" refers to physical layers. For example, PLC-1 in dwelling A accepts a swept carrier system in a neighbouring dwelling.
- Different applications require different protocols. A given user may want a simple, low-cost system that requires a straightforward protocol, while the neighbour's system might be highly sophisticated. When different dwellings within a PL network use a common (physical layer) PLC technology, each packet must carry the identification of the protocol in use. Protocol Identification (PID) allows applications, whether simple or complex, current or forthcoming, to share a common PL network. Even in one given dwelling, single applications may use more than one protocol.
Let us go one step further. What happens if two neighbouring dwellings use the same physical-layer PLC technology and the same protocol? When dwelling A sends a command to turn all lights off, it would be convenient, to say the least, not to turn off all the lights in dwelling B at the same time! The solution is to use addressing to ensure that nodes exclusively process packets relevant to a given dwelling, while excluding all other packets. Typical addressing schemes consist of a System Address (SA) for dwelling addressing and a Node Address (NA) for unit addressing within a given dwelling. For shared PL system applications, each packet includes the complete Destination address (DSA and DNA). Note that a given packet might be addressed to multiple nodes, where DNA would represent a group of nodes; DSA, however, must never address neighbouring systems.
Traveling packets must inform routers and repeaters about the node from which they originate. For example, say a router links a PLC network with a local Twisted Pair (TP) network; this router must not forward packets coming from dwelling B to the TP network in dwelling A. To work properly, routers require the source and destination addresses. General nodes in a network must not notice the presence of routers or repeaters, therefore each and every packet should include both the destination and the source addresses: DSA, DNA, (destination addresses) and SSA, SNA (source addresses).
| PID | DSA | DNA | SSA | SNA |
Some PLC technologies allow source addresses omission in a packet, but such a specification will impede functions like routers and repeaters. Other PLC technologies that use repeaters risk endless repeating if a second repeater is installed in a neighbouring dwelling. Certain applications require rejection of duplicate packets; UNACK packets, for example, are routinely repeated to increase the probability of successful delivery. However, duplicate, i.e., repeated and redundant packets may not be interpreted twice by the receiver as variable incrementing, for example, could result in inaccurate variable values. Source addresses are required for duplicate packet identification and subsequent rejection, and PLC technologies that do not always transmit the source address with the packets hinder the duplicate rejection process.
- Multiple dwellings share a given PL network and potentially use different, incompatible PLC systems. A well-designed PLC technology tolerates the presence of foreign PLC technologies on the network.
- Multiple protocol support is a requirement and a well-designed PLC technology transports multiple protocols within one PL network, enables applications to use more than one protocol, and identifies the protocol in use.
- Well-designed PLC systems avoid inter-dwelling communication and do not change nor even query neighbouring systems. Privacy must be preserved.
- Well-designed PLC systems consistently use addresses made up of both a SYSTEM (dwelling) address and a NODE (unit within the dwelling) address. Both the destination and the source addresses should be included.
