Complete Smartgrid Handbook Version 5

An introduction to
Smart Grid
Industrial Communications
Handbook
Revised 5th Edition
Michael A. Crabtree
crabtree
Controls Ltd.
‘Industrial Communications Handbook –
The Smart Grid’
5th Edition
by Michael A. Crabtree M.Sc.
Copyright © Michael A. Crabtree M.Sc.
All rights to this publication and to any associated workshop are reserved.
No part of this publication or associated software may be copied, reproduced, transmitted or

stored in any form or by any means (including electronic, mechanical, photocopying,
recording or otherwise) without prior written permission from the author.
Disclaimer
Whilst all reasonable care has been taken to ensure that the description, opinions, programs,
listings, software and diagrams are accurate and workable, neither the author nor the
publisher accept any legal responsibility or liability to any person, organisation or other entity
for any direct loss, consequential loss or damage, however caused, that may be suffered as a
result of the use of this publication or any associated workshop or software.
Neither the author nor the publisher endorse any referenced commercial products nor make
any representation regarding the availability of any referenced commercial product at any
time. The manufacturer's instructions on use of any commercial product must be followed at
all times, even if in conflict with the information in this publication.
i
Foreword
First and foremost this book, ‘Industrial Communications Handbook – The Smart Grid’
is a ‘Primer’ – a book providing a basic introduction to the subject of data communications
when applied to Smart Grids. Secondly, it’s complete in that it looks at all the current
technologies related to Smart Grids. And lastly it is a ‘definitive guide’ because it represents
a wealth of experiential knowledge gleaned from the author's involvement within a systems
integration company and also feedback from more than 4000 technicians and engineers who
have attended the author’s workshops.
I offer no apologies for my preference for metric-based measurement – the SI system. Apart
from the United States, only two other countries in the world still adhere to the fps system
(foot-pound-second) – the so-called Imperial system first defined in the British Weights and
Measures Act of 1824 – Burma and Liberia.
I’ve tried to mix it up as far as possible and I’ve got units conversion table right in the front
of the book. But for the moment try the following:
1 bar = 100 kPa ൎ 1 atmosphere ൎ 14.7 psi
1 inch = 25.4 mm
20 °C = 68 °F
100 °C = 212 °F
And lastly, I reserve my right to spell according to the British system:
English USA
metre meter
litre liter
fibre fiber
colour color
ii
iii
About the Author
Mick Crabtree
Michael (Mick) Crabtree joined the Royal Air Force as an apprentice at
the age of 16. Trained in aircraft instrumentation and guided missiles he
completed a Higher National Certificate in Electrical Engineering, (with
distinction in Mathematics) and concluded his service career seconded to
the Ministry of Defence.
In 1966 he moved to South Africa where he was involved in the sales of

industrial equipment and process control instrumentation, working at the
forefront of technology – moving from sales, to sales management, to
marketing management.
In 1981 he was appointed Editor and Managing Editor of South Africa's leading monthly journal dedicated to
the general electronic and process control instrumentation industries. In 1989 he founded his own company –
specialising in feature writing, articles, general PR, and advertising for the industrial process control sector.
During this period he also wrote and published seven technical handbooks on industrial process control: ‘Flow
Measurement’, ‘Temperature Measurement’, ‘Analytical On-line Measurement’; ‘Pressure and Level
Measurement’; ‘Valves’; ‘Industrial Communications’ and ‘The Complete Profibus Handbook’.
For the last twelve years he has been involved in technical training and consultancy and has run workshops on
industrial instrumentation and networking throughout the world (USA, Canada, UK, France, Southern Africa,
Trinidad, Middle East, Australia, and New Zealand). During this period he has led more than 4500 engineers,
technicians and scientists on a variety of practical training workshops covering the fields of Process Control
(loop tuning), Process Instrumentation, Data Communications, Fieldbus, Safety Instrumentation Systems
(according to both ISA S84 and IEC 61508/61511), Project Management, On-Line Liquid Analysis, and
Technical Writing and Communications.
After nearly 35 years spent in South Africa, he now lives in Wales, just outside Cardiff, having relocated to
Britain about fourteen years ago.
Mick holds a Masters Degree from the University of Huddersfield.
His hobbies and pastimes include: cycling, rambling, history, and reading.
iv
v
Contents
Foreword ii
The author iv
Contents vi
Units conversion ix
Chapter 1. Introduction to the Smart 1

Chapter 2. Networking and topologies 5
Chapter 3. Industrial Ethernet 11
Chapter 4. Internet Protocol (IP) 25
Chapter 5. Transmission Control Protocol (TCP) 41
Chapter 6. DNP3 51
Chapter 7. IEC 61850 65
Chapter 8. Spanning Tree Protocol (STP) 73
Chapter 9. Rapid Spanning Tree Protocol (RSTP) 85
Chapter 10. Multiple Spanning Tree Protocol (MSTP) 91
Chapter 11. Building Automation and Control network (BACnet) 97
Chapter 12. LonWorks 104
Chapter 13. Wireless 111
Bibliography 133
vi
Units conversion
Quantity SI US customary
Distance 25.5 mm 1 in
1 millimetre 0.03937 in
1m 39.37 in
1m 3.281 ft
0.9144 m 1 yd
Area 1 square metre (m2) 1550 in2
1 square metre (m2) 10.76 ft2
1 square millimetre (mm2) 0.00155 in2
Volume 1 cubic metre (m3) 61.02 in3
1 cubic metre (m3) 35.31 ft3
3
0.02832 m 1 ft3
1 litre 61.02 in3
1 litre 0.03531 ft3
1 litre 0.2642 gal
3.785 litres 1 gal
Mass 1 kg 2.205 lb
454 g 1 lb
Force 1N 0.2248 lbf
4.448 N 1 lbf
Pressure 1 bar 14.504 lbf/in2 (psi)
1 bar 100 kPa
10 bar 1 MPa
2
1 kPa (kN/m ) 0.145 lbf/m2 (psi)
6.895 kPa 1 psi
Temperature K 1.800 °R
°C 1.8 °C + 32 = °F
3
Flow rate 1 m /h 4.403 gal/min (gpm)
1 kg/h 2.205 lb/h
viii
ix
Chapter 1. Introduction to Smartgrid
O
ver the last five years, many changes have taken place in the field of Data
Communication. There have been some small but significant ‘tweaks’ to some of the
existing technologies; and there’s been a huge uptake in the use of wireless
technology – with still no end in sight to the so-called ‘Wireless Wars’.
And then there’s the ‘Smart Grid’.
What’s a Smart Grid?

My eyes were recently irresistibly drawn to an article entitled “Majority of Americans don’t
understand smart grid, study says”.
Apart from the somewhat convoluted English, the biggest surprise lay in the statement: “The
majority of Americans have heard of the Smart Grid, but most don’t know what it is.”
Really? The average American is that well-informed? Do you really think that the same
statement could be applied to South Africa or, for that matter even to Britain? I have my
doubts. A recent survey as to the nature of Smart Grid, conducted in the bar of my local
rugby club, elicited not a single intelligent response – mind you, the hour was late and Wales
had, once again, just won the six Nations – beating England 30 points to 3. But still…
So what exactly is it?
From a global perspective the Smart Grid can be understood as a range of technologies that
contributes to a more efficient and more reliable power distribution system.
Of course, that’s possibly so ‘global’ as to be almost meaningless. So let’s drill down a little.
From its inception the power distribution grid was created as a two-way simplex service:
power flowing from the generating station to the consumer; and one-way communication of
the energy consumed (often by phone or mail) sent back to the provider.
Currently, a relatively small number of very large facilities, strategically located close to
fossil fuel reserves, generate most of the power which, because of the difficulties involved in
storing energy in sufficient quantities, must either be used immediately or wasted.
Consequently, power supply providers must provide a sufficiently large and expensive
infrastructure to support the peak demand when required in order to avoid major power
outages. Indeed, in order to support these peak demands, the US Department of Energy
(DOE) estimates that 10% of the power generation and 25% of the distribution infrastructure
is only used 5% of the time.
Chapter 1. Introduction to Smartgrid 2
It might be said that the primary function of a

power supply provider is to produce, distribute,
Another (frightening) report from the
and deliver energy to the end user. The on-going
US DOE states that, “In many areas
of the United States, the only way a
goal of the provider is thus to achieve those tasks
utility knows there’s an outage is through a fully integrated, automated and remotely
when a customer calls to report it.” supervised system that requires minimal human
intervention.
At its basic level, therefore, the primary role of a Smart Grid could be seen as a system for
providing an automated demand response strategy that equalises load distribution – flattening
demand spikes and thus eliminating the cost of adding reserve generation.
Such load balancing, conducted on a national basis, becomes even more challenging with the
increasing use of intermittent and variable alternative power sources such as wind turbines
and solar cells that need to be integrated into the grid. This implies a move from a centralised
grid topology to a distributed topology – with power being consumed and generated at the
limits of the grid.
However, such a system would also need to support substation automation, asset
management, equipment monitoring, wide-area monitoring and control, reliability-centred
maintenance (RCM) as well as the associated data access security.
In this regard, the DOE lists five fundamental technologies that will drive the Smart Grid:
 Integrated communications, connecting components to open architecture for real-time

information and control, allowing every part of the grid to both ‘talk’ and ‘listen’
 Sensing and measurement technologies, to support faster and more accurate response
such as remote monitoring, time-of-use pricing and demand management
 Advanced components, to apply the latest research in superconductivity, storage, power
electronics and diagnostics
 Advanced control methods, to monitor essential components, enabling rapid diagnosis
and precise solutions appropriate to any event
 Improved interfaces and decision support, to amplify human decision-making,
transforming grid operators and managers quite literally into visionaries when it comes to
seeing into their systems
From the foregoing it can be seen that it is almost axiomatic that a key element of such a
Smart Grid lies in the use of an integrated digital communications network – catering for
real-time data exchange and control. Such integrated communications would also lead to
increased reliability and security through the use of self-healing digital communication
networks and improved equipment diagnostics through device interrogation.
It is also axiomatic that substations not only facilitate the efficient transmission and
distribution of electricity but play a vital role in terms of monitoring and controlling power
flows and provide the interconnection between generating facilities, transmission and
distribution networks and end consumers. Substation Automation (SA) makes control and
monitoring possible in real-time and helps maximize availability, efficiency, reliability,
safety and data integration. Any communication network, therefore, also needs to support
substation automation asset management, equipment monitoring, wide-area monitoring and

control, reliability-centred maintenance (RCM) as well as the associated data access security.
From the viewpoint of this handbook, therefore, one single question remains: which digital
communications system should we use?
Obviously, similar to the requirements for a conventional industrial digital network, there is
no one single technology that meets all the needs. Consequently, we are going to see a mix of
protocols* and technologies, all of which should (ideally) provide seamless connectivity – a
goal which has yet to be realised in the industrial environment.
So we thought it would be fitting to look at some of the systems that are used in Smart Grid
applications. So it’s time to dust off some of the systems that have been sitting in relative
obscurity: DNP3; BACnet; LonWorks; LonTalk; and probably the main contender for the
system backbone – IEC 61850.
* Protocol
Let’s get this term ‘protocol’ pinned down properly.
A protocol is simply a set of rules that governs communications within a data communications
network. A protocol defines everything from how connections are made between devices to how
the message itself is formatted. Protocols can be implemented through software, hardware, or
both.
It is the widespread acceptance and use of standard protocols that has enabled the development
of many of today’s communications systems – including local area networks and the Internet.
Unfortunately, the reverse is also true and it is the lack of standard protocols in the field of
industrial data communications that have led to so many competing systems.
Chapter 2. Networking and topologies
T he physical layout (or topology) of a network is usually implemented as one of four

forms: bus (or multi-drop), star, ring and mesh.
Bus topology
In a bus topology (Figure 2.1) all nodes connect to a common media – often called the
backbone. Only one node can transmit at a time. All nodes ‘hear’ all communications and
thus while one node is transmitting all the others are listening. However, only the station to
which the data is addressed will take notice of the message.
Node 1 Node 2 Node 3 Node 4
Figure 2.1. In a bus topology all nodes connect to a common media and only one node can
transmit at a time.
Variations in the bus topology include: daisy chain; tree; and mainline/trunkline as shown in
Figure 2.2.
Distribution Distribution Distribution
Terminator point point point Terminator
NODE NODE
NODE
Daisy chain NODE NODE

Distribution
Mainline/trunkline point
Tree NODE NODE
NODE
Figure 2. 2. Daisy chain; mainline/trunkline; and tree configurations.
Since any of the nodes on the bus network can send data at any time, a number of protocols
have been developed to regulate access of the devices onto the bus and thus avoid data
collisions.
A major benefit of the bus topology is that it is a relatively easy to install and nodes are easily
added or removed. On the downside, a break in the cable will affect the whole bus.
A major consideration in a bus network is the need to prevent reflections through the use of
terminators.
Star topology
In the star topology each node has its own network segment that links it back to a central
host, called the hub, which controls all communications (Figure 2.3).
Hub
Node 1 Node 6
Node 2 Node 5
Node 3 Node 4
Figure 2.3. In star topology each node has its own network segment that links it back to a
central hub, which controls all communications.
Like star networks only one node can transmit at a time and each node must look at the data
to see if it has been addressed to it. In a star network a cable break will only effect the node
attached to that cable and all the other nodes will still be able to communicate. Unfortunately
if the hub fails then the entire network fails.
The star network is generally more expensive than the bus configuration because of the need
for the hub. In addition, it requires more cabling.
Ring (or Loop) topology

In the ring topology all of the nodes are connected to a single cable that forms a closed loop
or ring (Figure 2.4). Data flows only in one direction – with each node passing the data onto
the next node on the line. Each node must, therefore, be capable of regenerating the data
before passing it on. Further, the destination node must be capable of removing the data from
the network.
Node 6
Node 1
Node 5
Figure 2.4. In the ring topology all of the

nodes are connected to a single cable that
forms a closed loop or ring , with data flowing
only in one direction.
Node 2 Node 4
Node 3
Although the most economical, as far as cable is concerned, the major drawback of the ring
topology is that a break anywhere in the cable will cause the entire network to fail as will the
failure of any node. In practice the ring network is usually a collapsed ring that looks like a
physical star (Figure 2.5).
Ring wiring
concentrator
Figure 2.5. Ring network collapsed to look
like a physical star.
Node 1 Node 6
Node 2 Node 5
Node 3 Node 4
Tree topology
A tree topology (Figure 2.6) combines the characteristics of both star and bus topologies. In
its simplest form a hub connects directly to the bus – with each functioning as the root of a
tree of devices. The main advantage of this hybrid approach is that it supports future
expandability of the network much better than a bus (which is limited in the number of
devices due to the broadcast traffic it generates) or a star (which is limited by the number of
hub connection points) alone.
Hub/Switch
Hub/Switch
Hub/Switch
Node
Node
Node Node
Node Node
Node
Node
Node
Figure 2.6. A tree topology combines the characteristics of both star and bus topologies.
Mesh topology
In a mesh network each node is connected to several others and involves the concept of
routes – such that a message can take any of several possible paths from source to destination
(Figure 2.7).
Node 5
Node 1
Node 6
Hub/Switch H
D G
A
L
C J
Node 2 F
E Node 4 Node 7
K
B
Node 3
Figure 2.7. In a mesh network each node is connected to several others and involves the
concept of routes – such that a message can take any of several possible paths from source
to destination.
A major feature of mesh networking is that they are self-healing – catering for continued
communication in the event that a path should fail. Thus, the most direct route to the
Hub/Switch for Node 1 would be Link D. However, in the event of its failure, the
transmission might be routed through Link A to Node 2; Link B to Node 3; and then Link E
to the Hub/Switch.
The real advantages of mesh networks are that they improve data reliability by providing
multiple redundant paths in areas where a lot of nodes are in use. They are not designed,
however, for every application. It takes time for paths to form and devices to associate, and
additional system delay occurs as messages must be forwarded on through the network.
Because mesh networks involve multiple paths, the network protocol must be capable of
building and maintaining routing tables to prevent messages taking ‘looped’ routes.
We shall see how ‘looped’ routes are avoided in subsequent chapters on Spanning Tree
Protocol and its derivatives.
Chapter 3. Industrial Ethernet
O
riginally developed by Xerox, Ethernet is based on the ALOHA radio network set
up at the University of Hawaii. An Ethernet consortium, comprising Xerox, DEC
and Intel, the DIX consortium, gave rise to what is termed the `Ethernet Blue
Book 2' specification or more commonly, ‘Ethernet II’. In 1983, the IEEE in an effort to
develop an open network standard, issued the IEEE 802.3 specification.
The Ethernet standard defined by the IEEE 802.3 specification defines the network-to-
operations called for in the Physical and Data Link Layers. This covers rules for
configuring Ethernet LANs, the type of media that can be used, and how the elements of
the network should interact.
Ethernet is a peer-to-peer network based on the CSMA/CD access protocol and which uses
‘baseband’ transmission. As distinct from a ‘broadband’ transmission system, in which a
number of transmissions can take place simultaneously using multiple carriers, Baseband
transmission uses the full bandwidth of the system for a single transmission.
Ethernet networks can be configured in either star or bus topology and installed using any
one of three different media as defined by the IEEE 802.3 standard.
Frame format
Figure 3.1 shows the IEE 802.3 frame format.
IEEE 802.3 frame 64 to 1518 bytes
Frame
Destination Source Length/
Preamble SFD Data Pad Check
Address Address Type
Sequence
7 bytes 1 byte 6 bytes 6 bytes 2 bytes 46 to 1500 bytes (Optional) 4 bytes
Figure 3.1. The IEE 802.3 format.
Preamble and SFD

In the IEEE 802.3 frame, the Preamble comprises a group of 7 bytes – each with the data
pattern 10101010. In an industrial Ethernet system, this produces a 100 MHz square-
wave that is used to synchronise the receiver clock to that of the transmitter.
This is followed by the Start Frame Delimiter (SFD) comprising a single byte with the
pattern 10101011 and is recognised by the receiver as the commencement of the address
field.
It should be noted that the preamble is not considered as part of the frame when
considering the overall frame size.
Destination/Source Addresses
Each NIC is assigned a 6-byte unique permanent address often referred to as the ‘MAC
address’ or more simply, the ‘Adapter Address’. This means that, theoretically, a total of
248 (2.8 x 1014) addresses is available. In reality, the 6-byte field is split into two three-
byte blocks in which the first block is assigned to a specific manufacturer by the IEEE
Standards Association (http://standards.ieee.org/regauth/oui/) The second block allows the
vendor to provide a unique identifier for each device they build (i.e. 16 million possible
addresses).
When a frame is broadcast, each Ethernet device attached to the network reads in the frame
up to at least the Destination Address. If it does not match the device’s MAC address the
interface ignores the rest of the frame.
Note. The Source Address is not used by the MAC protocol but is transmitted as an
aid for higher level protocols.
Length/Type Indicator
In the original Ethernet II standard it was always intended that the Data Link Layer
would not provide a guaranteed delivery of data but that this would be carried out
by a higher level protocol. As a result this 2-byte field was used to identify the
Type of higher level protocol carried within the data field. A hexadecimal value of
0x0800 for example refers to an IP packet.
In the IEEE 802.3 standard, this field is now the Length/Type field – with the value of
the hexadecimal number indicating its role. The maximum length of the data field is 1500
and thus if the value is 1500 (0x05dc) or less the field is indicating Length.
As we shall see later, the minimum size of the data field is 46 bytes. If the number of
bytes is likely to be less, then pad data must be added automatically to bring it up to a
total of 46 bytes. Thus the length field is used to determine whether the pad data needs to
be retained or discarded.
But if the value is 1536 (0x0600) or more, the field is indicating Type and is designating
the type of higher level protocol. The range 1501 to 1535 (0x05dd to 0x5ff) is purposely
left undefined.
Data
The data field can vary in length from a minimum of 46 bytes to a maximum of 1500
bytes. If a message is greater than 1500 bytes a higher level protocol can be used to carry
out fragmentation and sent in subsequent frames.
Pad
The Pad field is used to pad out any frame which does not meet the minimum data frame
length. Since the value in the Length field must be valid, the receiver can discard the pad
data as being irrelevant.
FCS
Frame Check Sequence based on a 32-bit CRC (Cyclic Redundancy Check).
Note. The Ethernet Data Link Layer contains no mechanism to inform the transmitting
node that a reception was accepted or rejected. This task is left to an upper level protocol.
Medium access control

When a node wishes to transmit, it must first monitor the bus and ascertain that there is no
traffic. This is the ‘carry sense’ component of the CSMA/CD protocol. Once the bus is
quiet, the node continues to defer for a further 96 bit times (at 100 Mbps this is 0.96 s)
referred to as the Interframe Gap (IFG). The node is now free to transmit a single frame
and, in the example shown in Figure 3.2, Station A commences transmitting. While it is
transmitting it is also listening to ensure that no other nodes have started transmitting
simultaneously (Figure 3.2 (a)).
Station A
10101010
(a)
Station A
Station B Figure 3.2 (a + b). Collision
detection
1010101010
10101010
(b)
Station B
If at this point, before the signal from Station A has time to propagate down the bus, Station
B has also listened and found the bus to be quiet, it too is free to transmit (Figure 3.2 (b)).
A short time later when the signals ‘collide’ the overlap will cause the d.c. voltage level to
rise (Figure 3.3 (c)). This ‘collision’ now propagates down the line in both directions.
Since Station B is a closer to the collision point it will be the first to detect that the bus
levels differ from those which it has been transmitting and that a collision has occurred
(Figure 3. 3 (d)).
Station A
Collision produces
abnormal voltage
on bus
(c)
Station A
Station B
Figure 3.3 (c + d). Collision
detection
Collision propagates in both directions
but reaches station B first
(d)
Station B
Station B immediately sends a ‘Jam’ signal of 32 bits (Figure 3.4 (e)) and stops
transmitting. When the collision has propagated as far as Station A, it too recognizes that a
collision has occurred and sends a jam signal (Figure 3.4 (f)). Both stations now back off
for an individually random period of time, determined by a back-off algorithm, before
being allowed to listen on the bus again.
Station A
Station B produces
jamming signal
Figure 3.4 (e + f). Collision

detection
(e)
Station A
Station B
Station A produces Jamming signal

jamming signal from Station B
(f)
Station B
It should now be apparent that the ‘CSMA’ aspect of Ethernet implies that any random
signal found on the bus will prevent all nodes from gaining access. More specifically, any
node that becomes faulty and broadcasts continuously will jam the whole system. Each
NIC therefore incorporates a `Jabber' control that disconnects the node from the bus
should it detect excessive transmission activity.
Slot time
Plainly, collision detection is an important aspect of the CSMA/CD system. In other words,
if two nodes transmit simultaneously, a collision must occur. If the distance between
Station A and Station B (Figure 3.4 (f)) is sufficiently long, so that by the time the
‘collision’ has propagated as far as Station A it has finished transmitting its frame then,
very simply, Station A’s frame will have been corrupted but it will not be aware of the fact.
From the foregoing it is thus apparent that for a collision to be detected, the total
propagation time from one end of a maximum-sized network to the other and return must
be less than the frame period. For a 100 Mbps Ethernet system this time, known as the slot
time, is taken as 512 bit times e.g. 5.12 s. Put another way, the time it takes to transmit a
512-bit frame is slightly longer than the actual amount of time it takes for the signals to get
to one end of a maximum sized Ethernet.
Back-off algorithm
The back-off algorithm is designed so that if a collision is detected, the transmitting stations
are backed off for an individually random period of time, before attempting a new
transmission sequence.
The back-off period is an integer multiple of the slot time which, for a 100 Mbps system, is
5.12 s. The integer (r) that is used to multiply the slot time is calculated as:
0  r < 2k where k = min (n, 10)
The value of r can thus range from 0 to one less than 2 to the exponent k . And the variable
k is the number of transmission attempts (collisions) – limited to a maximum of 10. Thus,
as the number of collisions increases, the range of the back-off times will increase
exponentially to a maximum of r = 1023. This is shown in Table 3.1.
Table 3.1. Range of back-off times on a 10 Mbps system. Back-off times increase
exponentially with the number of collisions.
Collision Range of random Back-off time

number (k) numbers (r ) (s)
1 0–1 0 – 51.2
2 0–3 0 – 153.6
3 0–7 0 – 358.4
4 0 – 15 0 – 768.0
5 0 – 31 0 – 1 587.2
6 0 – 63 0 – 3 225.6
7 0 – 127 0 – 6 502.4
8 0 – 255 0 – 13 056.0
9 0 – 511 0 – 26 163.2
10 0 – 1023 0 – 52 377.6
11 0 – 1023 0 – 52 377.6
12 0 – 1023 0 – 52 377.6
13 0 – 1023 0 – 52 377.6
14 0 – 1023 0 – 52 377.6
15 0 – 1023 0 – 52 377.6
16 N/A Discard frame
Although the back-off time is capped after collision number 10, if the station continues to
encounter collisions after 16 attempts, the frame is discarded.
This is called a Truncated Binary Exponential Back-off Algorithm where binary

exponential refers to the power of 2, and truncated signifies the limit set on the size of the
exponential.
Assume two Stations A and B begin to transmit simultaneously and produce a collision.
Both are backed off for either 0 or 1 slot times i.e. 0 or 51.2 s. There is now a 50-50
chance that they will both have the same value and thus again start transmitting
simultaneously. On the second collision they will now back off for either 0, 1, 2 or 3 slot
times – reducing the probability of a collision to 25%.
If we assume that Station A wins the contention, its collision timer is cleared to zero whilst
the collision timer of Station B will continue to increment – backing off for 0, 1, 2, 3, 4, 5,
6 or 7 slot times.
Now, let’s see what could happen.
Again assume that Stations A and B attempt to transmit simultaneously and produce a
collision. Both are backed off and on the next collision Station A wins the contention and
its collision timer is cleared to zero. In the meantime the collision timer of Station B will
increment to 0, 1, 2 or 3 slot times.
Station A, in the meantime wishes to transmit more data. But, because its collision time has
been set to zero it’s starting off with an advantage and there is thus a greater probability of
it winning contention.
If again Station A wins contention, and its collision timer is cleared to zero, Station B is at
an even greater disadvantage since it is now backed off for 0, 1, 2, 3, 4, 5, 6 or 7 slot times.
The problem now is that any new station wishing to transmit data will have an advantage
over Station B. This phenomenon, called channel capture, shows that access to the
network is neither fair nor predictable.
However, the reality is that few users actually experience channel capture. It is important to
appreciate that in the preceding example, Station B is not required to pick the largest
integer but any single one in the range it has been allocated. This could just as well be 0 as
a higher number. Further, segmentation using switching hubs limits the number of nodes
contending for access on any given channel and this again reduces the possibility of
channel capture.
Hubs and switches

Until the advent of switching technology, networks made use of a (physical) star topology
in which in the nodes are connected to a hub or concentrator – with a maximum node-to-
hub length of 100 m. Clearly, this limited the size of the Local Area Network (LAN) –
generally confining it to a fairly small location e.g. a single building.
The cable comprised two pairs – one for transmitting and the other for receiving – and is
terminated at each end with RJ-45 connectors. As shown in Figure 3.5, the hub provides
internal buffering for input and output. Although the physical topology is a star, the
internal buffering at the hub allows the system to be considered as a logical bus topology.
Network Interface Network Interface Network Interface

Card (NIC) Card (NIC) Card (NIC)
Tx Rx Tx Rx Tx Rx
Figure 3.5. Hub provides internal
buffering for both input and output.
Rx Tx Rx Tx Rx Tx
Hub
The advent of the ‘switch’ to replace the formerly used ‘hub’ in Ethernet technology,
opened a new vista in networking possibilities – moving away from the constraints of
what was essentially a ‘star’ based topology to Wide Area Networks (WANs) and
complex mesh layouts.
Unlike a hub, a switch does not simply transmit the frame to every port but will
determine the datagram’s destination by first checking the MAC address and then
forwarding it to the appropriate port. In this manner none of the other nodes connected
to the node will be sent the datagram.
When a switch is first powered on, its MAC filter table is empty. Assume Node 1
transmits a datagram addressed to Node 3 (Figure 3.6). Since the MAC filter table is
empty, and the switch has no indication of the location of any of the nodes, the
datagram will be forwarded to Nodes 2, 3, 4 and 5. At the same time the switch places
the Node 1’s source address in the MAC filter table – remembering the interface
(Interface 1) to which Node1 is connected.
Figure 3.6. Since the switch

has no indication of the
Node 5 Node 4 location of any of the nodes,
Switch the datagram will be
forwarded to Nodes 2, 3, 4
Interface 5 Interface 4 and 5. In addition, the switch
stores Node 1’s source
Interface 1 Interface 3 address in the MAC filter
Interface 2 table whilst also remembering
Node1
the interface (Interface 1) to
which Node 1 is connected.
Node3
Node2
Assume now Node 3 answers and sends a datagram back, the switch will place its
source address in the MAC filter table – associating this address with the interface that
received the frame. Since the switch has two MAC addresses in the filter table, the
devices can make a point-to-point connection and the datagrams will only be forwarded
between the two devices (Figure 3.7).
Node 5 Node 4
Switch
Interface 5 Interface 4
Interface 1 Interface 3
Interface 2
Node1
Figure 3.7. When Node 3 answers
and sends a datagram back, the
Node3
switch will place its source
address in the MAC filter table –
associating this address with the
interface that received the frame.
Node2 Since the switch has two MAC
addresses in the filter table, the devices can make a point-to-point connection and the
datagrams will only be forwarded between the two devices
Typically, switches can hold up to 8000 MAC addresses. However, once the table is
full, and this might take only a few minutes, the switch will start over-writing the
entries – starting with the first MAC address entry. Consequently, if a node remains
quiescent for more than 5 minutes (the default time), its MAC address may well have
been removed from the filter table. Subsequently, any datagrams destined for this
particular node will be forwarded to all the ports on the switch.
In summary the switch analyses all the data packets as they arrive and directs them onto
the port where the corresponding user is located (Figure 3.8). Each switch requires an
address/port assignment table in order to correctly redirect the datagrams – with the
assignment of a destination address to a specific port in the switch being stored in this
Assignment Table
table.
Address Port
1234 1
A47B 3
3456 4 Figure 3.8. The address/port
AAB1 2
assignment table redirects the
Switch Matrix datagrams to a specific port in the
Ethernet Data Ethernet Data
switch.
Ports Ports
The destination address of an incoming data packet is analysed with the aid of this
table, and the data package is passed on immediately to the corresponding port.
Collision domains
Previously we have seen that Ethernet based on CSMA/CD is probabilistic – making it
unsuitable for use in industrial applications where the need is for real-time (deterministic)
communications.
However Ethernet is probabilistic only if collisions are allowed to occur. It thus follows that
in order to implement a deterministic system, collisions must be avoided. This may be
implemented through the use of switches and full duplex links.
The term collision domain refers to a single Ethernet system in which all the nodes are part
of the same signal timing field. In other words, if two or more nodes transmit at the same
time, a collision will occur. A collision domain may include several segments (Figure 3.9)
linked together with repeaters (hubs).
Repeater (Hub)
H Repeater (Hub)
H
Figure 3.9. A collision domain
may include several segments
linked together through hubs
(repeaters).
Segment 1 Segment 2
Single collision domain
In Figure 3.10, two collision domains are linked using a switch. Unlike a repeating hub,
each switch port acts as though it were the originating device by assuming its source
address. In this manner the collision domain is now terminated at the switch port –
effectively segmenting the network into separate collision domains.
Switch Switch Switch

port port
Switch H
H
H
port H
H Collision domain
Collision domain H
Collision domain
Figure 3.10. Linking two collision domains with a switch effectively segments the
network into separate collision domains.
It is important to recognise that communication within a single collision domain is half-

duplex: a node either transmits or receives but cannot perform both actions at the same
time. However, if each collision domain were only a single device (Figure 3.11) full-
duplex operation is possible with, consequently, no collisions.
Switch Segment 3 with

full-duplex operation
Segment 1 with
Segment 2 with
Figure 3.11. If each collision domain were only a single device full-duplex operation
is possible with, consequently, no collisions.
LANs to WANs
Let’s step back a moment and look at a conventional hub-based LAN, in which the nodes
communicate over a star-connected topology. As illustrated in Figure 3.12, communication
with other LAN segments to form a Wide Area Network (WAN), requires the use of routers –
whose interfaces are actually part of the associated LAN collision domain.
A major drawback to the use of routers is that in order to determine destinations, and route
the data to the appropriate end node, they require a large overhead and thus add latency*.
* Latency is the delay between the time a device requests access to a network and the time it
is granted permission to transmit. It is also the delay between the time when a device receives
a frame and the time that frame is forwarded out the destination port.
Router
H
LAN 3
Repeater (Hub)
WAN
Repeater (Hub)
Repeater (Hub)
H
H
LAN 1
Router LAN 2
Figure 3.12. Communication with other LAN segments, to form a WAN, requires the use
of routers – whose interfaces are actually part of the associated LAN collision domain.
Virtual LANs (VLANs)

A Virtual LAN (VLAN) is a group of devices that are on different physical LAN segments
but which can communicate with each other as if they were all on the same physical LAN
segment. This allows users to define broadcast domains without the constraint of physical
location and also improves security. This is particularly relevant in, for example, separating
process control systems from IT systems.
Whilst the creation of VLANs was possible using a hub-based system, together with routers,
it was at best a clumsy solution. However, another major feature of a switch is that it can
partition a LAN into several smaller VLANs to create the same network divisions, within
separate broadcast domains, but without the latency problems of a router.
A switch cannot do this, however, by itself and needs to be instructed. This is the role of the
VLAN tag.
VLAN tag
In order to implement the creation of VLANs IEEE 802.1p/q has introduced a 4-byte
‘VLAN’ tag (Figure 3.13).
IEEE 802.1q VLAN tag 64 to 1522 bytes
Frame
Destination Source VLAN Length/
Preamble SFD Data Pad Check
Address Address tag Type
Sequence
7 bytes 1 byte 6 bytes 6 bytes 4 bytes 2 bytes 46 to 1500 bytes 4 bytes
1 bit
Priority
Tag type VLAN

CFI
0x8100 Identifier
16 bits 12 bits
3 bits
Figure 3.13. 4-byte VLAN tag according to IEEE 802.1p/q.
As shown, the tag is inserted into the Ethernet frame between the Source Address and
Length/Type fields and raises the total number of bytes in the frame from 1518 to 1522.
Let’s deal with the two most important fields first:
VLAN Identifier (VID): this 12-bit field uniquely identifies the VLAN to which the Ethernet
frame belongs. Whilst the values of 0x000 and 0xFFF are reserved, all other values may be
used – allowing up to 4 094 VLANs.
Priority Code Point (PCP)

Having implemented a pseudo-deterministic system through the use of switches and full
duplex links, we’ve now got a democratic system and taken out the element of ‘unfairness’
due to collision detection. However, there is still a remaining problem – real-time packets
will always be added to the end of the queue on a first-come first-served basis.
The 3-bit field PCP field provides a mechanism for prioritisation by prioritizing different
classes of traffic. A ‘1’ represents the lowest priority whilst ‘7’ represents the highest .
The remainder of the tag is structured as follows:

Tag Protocol Identifier (TPID): a two-byte field that is always set to 0x8100 to indicate the
presence of an IEEE 802.1q VLAN tag. This field is located at the same position as the
EtherType/Length field in untagged frames, and is thus used to distinguish the frame from
untagged frames.
Drop Eligible (DE): a 1-bit field that may be used separately or in conjunction with PCP to
indicate frames eligible to be dropped in the presence of congestion. This field was formerly
designated the Canonical Format Indicator (CFI) which was used for compatibility reasons
tween Ethernet and Token Ring networks. It is always set to ‘0’ for Ethernet switches.
Chapter 4. Internet Protocol (IP)
W hat may not have become clear in the preceding chapter on Ethernet is that for all
its sophistication, Ethernet only defines the bottom two layers of the OSI model:
the Physical Layer and the Data Link Layer. Without some form of upper layer
protocol management system, Ethernet by itself would be useless. It could not enable
communication between hosts* on different networks, perhaps separated by large
geographical areas. It could not guarantee the delivery of messages over a network or between
networks. And it certainly couldn’t provide fragmentation of messages that exceed the standard
Ethernet frame length of 1500 octets†.
* Hosts refer to the end-to-end devices (e.g. computers) used on the internet.
†
In order to conform to most of the literature produced on the subject of TCP/IP we will make use of the
term ‘octet’ (8 bits) in place of the term byte.
Today, the almost universally used protocol stack of choice is what is officially designated the
‘Internet Protocol Suite’, but more commonly referred to as simply, TCP/IP. The TCP/IP
protocol stack is, in reality, a complete suite of protocols and is named after its two most
important protocols:
Transmission Control Protocol (TCP); and

Internet Protocol (IP).
Figure 4.1 shows the TCP/IP protocol architecture. This is by no means exhaustive but
shows the major protocols and application components common to most commercial
TCP/IP software packages and their relationship.
OSI MODEL ARPA MODEL
7. APPLICATION
SNMP
FTP SMTP TFTP DNS
(Simple PROCESS AND
TELNET (File (Simple Mail (Trivial File (Domain
6. PRESENTATION Network APPLICATION 4.
Protocol Transfer Transfer Transfer Name
Management LAYER
Protocol) Protocol) Protocol) Service)
Protocol)
5. SESSION
TCP UDP SERVICE OR

4. TRANSPORT (Transmission Control (User Datagram HOST-TO-HOST 3.
Protocol) Protocol) LAYER
ARP ICMP
IP INTERNET
3. NETWORK (Address Resolution (Internet Control 2.
(Internet Protocol) LAYER
Protocol) Message Protocol)
2. DATA LINK Network interface card: Ethernet; Token Ring; ARCNET; etc
NETWORK
INTERFACE 1.
LAYER
1. PHYSICAL Transmission media: coaxial cable; twisted pair; fibre optics; wireless; etc
Figure 4.1. The ‘Internet Protocol Suite’ showing the IP residing at the Network layer and
the TCP at the Transport layer of the OSI Reference Model.
As indicated, the TCP/IP architecture is based on a 4-layer model that was originally
developed as part of a military project commissioned by the Advanced Research Projects
Agency (ARPA) – later known as the Defence Advanced Research Agency or DARPA. The
communications model used to construct the system is still known as the ARPA model.
When compared with the 7-layer OSI model it can be seen that although they were
developed by different bodies at different points in time, both serve as models for a
communications infrastructure with a high degree of similarity.
Data encapsulation
The Ethernet frame shown in Figure 4.2, comprising Preamble, Start of Frame Delimiter,
Source and Destination addresses, Length/Type field, Data field, Pad and Frame Check
Sequence, can be combined to form just three fields: Header, Data and Trailer fields.
1518 bytes
Start of Frame
Preamble Frame Destination Source Length/ Data Pad Check
Address Address type
Delimiter Sequence
Ethernet Ethernet
Header Data Trailer
Figure 4.2. The Ethernet frame can be combined to form just three fields:
Header, Data and Trailer fields.
The IP data, which sits above the Data Link layer, is called a Datagram and is inserted into
the Data field of the Ethernet frame (Figure 4.3.). This IP Datagram has it own header and
data fields but no trailer field. Similarly, data from the transport layer (in this example
TCP) – the layer sitting immediately above the IP layer – is inserted, together with its
header, into the data portion of the IP Datagram. The TCP data, plus its header, is termed a
Segment. And, finally, the application layer inserts its data (together with its own header)
into the data section of the TCP frame.
User Data
Process and
Application
Application
User Data
Header
TCP Header Application Data Transport Control

Protocol
IP Header TCP Header Application Data Internet Protocol
Ethernet Ethernet Network Interface

IP Header TCP Header Application Data
Header Trailer
Figure 4.3. Insertion of data from an upper layer into the data field layer immediately
below is called encapsulation.
Within the protocol stack, insertion of data from an upper layer into the data field layer
immediately below is called encapsulation. And the reversed process, extraction of the
same data at the receiving end, is called demultiplexing.
From the foregoing we thus understand that the information sent over the Data Link layer is
in the form of frames; the IP sends information down to the Data Link layer in packets that
are in the form of a Datagram or a fragment of a Datagram. And finally the TCP sends
Segments down to the IP.
Internet Protocol – general overview

The Internet Protocol is responsible for the addressing and routing of Datagrams and provides
addressing, routing and fragmentation. Residing at the network layer, the IP sends and
receives Datagrams received from upper layer software. These datagrams are fed to the
attached Data Link layer (in this case Ethernet) that sends and receives the Datagrams as a
series of packets.
Neither Ethernet nor IP provides a guaranteed data delivery service. In other words it does
not provide strict guarantees for the reception of data. Instead IP makes use of what is
termed a ‘best effort’ delivery service between source and destination addresses. This is
sometimes referred to as ‘connectionless’ because there is no formal session established
between the source and destination before the data is sent. Because IP does not guarantee
end-to-end message delivery it is frequently termed an ‘unreliable’ delivery service. The re-
sponsibility of ensuring that packets are not lost as they traverse the network is left to the
transport layer (TCP).
IP header
The IP header shown in Figure 4.4 consists of at least 20 octets made up by 5 x 4-octet
words. The first three words provide control information, whilst the fourth and fifth provide
address information. Further optional fields may be included in the header up to a
maximum of 60 octets.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Version IHL Type of Service (TOS) Total Length
Identification Flags Fragment Offset
Time to Live (TTL) Protocol Header Checksum
Source IP Address
Destination IP Address
Up to IP Options (often zero)

40 bytes
Padding
IP Datagram Data (up to 65 535 bytes)
Ethernet Ethernet
IP Header and Data
Header Trailer
Figure 4.4. The IP header consists of at least 20 octets made up by 5 x 4-octet words.
The fields contained in the header, and their functions, are:
Version
This four-bit field identifies the IP version. The current version of IP is version 4, so this
field will contain the binary value 0100. And the binary value 0110 identifies IPv6. The
differences between IPv4 and IPv6 are discussed later. Note: Other IP version numbers have
been assigned besides 4 and 6. For example 7 (0111) identifies TP/IX and 8 (1000) identifies
PIP.
Internet Header Length (IHL)

This four-bit field indicates how many 32-bit (4-octet words) are in the header. The
minimum length of the header is 20 octets so this field always has a value of at least 5 (0101).
Since the maximum value of this field is 15, the IP Header can be no longer than 60 octets.
This allows up to 40 octets for options.
Type of Service (ToS)

The 8-bit Type of Service (ToS) field allows an originating host to request different classes of
service for the packets it transmits.
The ToS field is intended to offer service precedence that treats high precedence traffic as
more important than other traffic and is a three-way trade-off between low delay, high
reliability, and high throughput. As shown in Figure 4.5, the field comprises a 3-bit field
offering up to 7 levels of precedence; a 4-bit ToS field; and an unused bit (LSB) set to 0.
8 9 10 11 12 13 14 15
Type of Service (TOS)
Precedence TOS Unused
Figure 4.5. The complete ToS field comprises a 3-bit precedence field; a 4-bit ToS field;
and an unused bit (LSB).
Although the precedence field appears to be a highly desirable feature, especially in control
networks that require low delay and high reliability, it would seem doubtful if the majority of
routers even look at these bits. Although this was a feature with great promise it was never
really implemented. This is to be rectified in IPv6.
The remaining 4 bits in the ToS field are turned on one at a time, and are nominated as
follows:
Bit 1: minimise delay
Bit 2: maximise throughput
Bit 3: maximise reliability
Bit 4: minimise monetary cost.
Total Length
This 16-bit field indicates the length (in octets) of the entire Datagram – including the header
and data. Given the size of this field, the maximum size of an IP packet is thus 216 = 65535
octets – the maximum size of the segment handed down to the IP from the protocol above it.
If the Datagram is larger than the maximum packet length that can be sent (e.g. 1500 octets
for Ethernet) it will need to be fragmented into manageable successive packets. In this case
the total length field will represent the length of the fragment sent and not the length of the
original datagram.
Identification
This is unique 16-bit number that identifies each Datagram sent by a host. Normally it will be
incremented by one each time a Datagram is sent. However, in the case of fragmentation, the
same Identifier is attached to all fragments of the same Datagram in order to reassemble the
Datagram at the receiving end.
Flags
This 3-bit ‘Flags’ field is also used for fragmentation and reassembly. The first bit is called
the More Fragments (MF) bit, and is used to indicate the last fragment of a packet so that the
receiver knows that the packet can be reassembled. The second bit is the Don't Fragment
(DF) bit, which suppresses fragmentation. The third bit is unused (and always set to 0).
If the ‘DF’ (Don't Fragment) is set to ‘1’ this informs the router not to fragment the datagram.
If this cannot be done an error message is returned.
If the ‘MF’ (More Fragments) bit is set to ‘1’ this indicates that there are more fragments to
follow. If the MF is set to ‘0’ this indicates that either the datagram is not fragmented (first
and only datagram) or it is the last fragment used in the fragmentation process.
Fragment Offset
This 13-bit field is used to indicate the position of the fragment within the original Datagram.
In the first packet of a fragmented stream the offset is 0. In subsequent fragments, this field
is used to indicate the distance or offset between the start of this particular fragment of data,
and the starting point of the original frame.
Fragmentation process
Consider a Datagram comprising an IP header plus 5616 octets of data. Since Ethernet has an
upper limit of 1500 octets this Datagram clearly cannot be transported over the network as a
single packet. The result is that it needs be fragmented – with, in this example, the Datagram
broken down into four separate packets. The first three packets will be around 1500 octets
and the last around 1200 octets.
On receipt of the packets by the receiver each packet will have been ‘stamped’ with the same
Identifier number and will thus all be recognized as fragments of the original Datagram.
However, because the four frames travel to their destination independently there is no
guarantee that they will arrive in the correct order. The role of the Fragment Offset is to thus
indicate the position of the fragment within the original Datagram.
As we have seen, the actual offset amount is divided by 8 before transmission. This means
that the data size (i.e. the offset) must be a multiple of 8. This means that a packet size of
1500 is not suitable. Further, the fragment size cannot exceed 1480 octets since 20 of the
1500 octets must be allocated to the IP header that must be sent with each fragment.
On this basis, the 5616 octets of data would be sent as three packets, each of 1480 octets
length, and a final packet of 1176 octets.
The procedure is shown in Figure 4.6. The first fragment is sent (together with its IP header)
with the DF flag set to 0 (the default); the MF flag set to 1 (indicating that more fragments
are to follow); and the Fragment Offset set to 0 (indicating that this is the first packet).
Original Datagram
IP
Data = 5616
Header
1st fragment 2nd fragment 3rd fragment 4th fragment
IP
Data = 1480 MF Flag = 1 Actual offset = 0 Fragment Offset = 0
Header
IP
Header
IP
Header
IP
Header
Figure 4.6. Fragmentation process.
The second fragment is now sent with the MF flag again set to 1 to indicate that more
fragments are to follow, and the Fragment Offset set to 185. This indicates the actual distance
(8 x 185 = 1480) between the start of this particular fragment and the starting point of the
first fragment.
The third fragment is sent with the MF flag still set to 1 (indicating more fragments to follow)
and the Fragment Offset set to 370. This again indicates the actual distance (8 x 370 = 2960)
between the start of this particular fragment and the starting point of the first fragment.
The fourth fragment is sent with the MF flag now set to 0 indicating that this is the last
fragment and no more are to follow. Now, the Fragment Offset is set to 555 indicating that
the distance between the start of this last fragment and the starting point of the first fragment
is 8 x 555 = 4440.
Where possible, fragmentation should be avoided since it increases data latency and increases
the chances of a corrupted datagram. Fortunately, in most control networks, fragmentation is
rarely an issue since control information packets do not usually exceed 256 or 512 octets.
Because only 13 bits are available for the Fragment Offset (instead of 16) and datagrams can
be 65535 octets in length, the actual offset amount is divided by 8 before transmission.
Time-to-Live (TTL)
This 8-bit (0 to 255) field is used by the routers to prevent a Datagram from a faulty
transmission sequence endlessly circulating around an internet. Each router that sees this
packet decrements the TTL value by one. When it gets to 0 the packet is discarded.
Originally the design called for the TTL to be decremented not only each time it passed
through a router but also for each second the Datagram is held up at a router for processing
(hence Time To Live).
In practice modern routers are much faster then earlier models and usually process the
Datagram within a second and only decrement the field by one (the minimum amount). As a
result, the field has come to be treated as a ‘hop’ counter in which a ‘hop’ is an instance of a
datagram being processed by a router.
Protocol
This 8-bit field indicates the next (higher) level protocol that resides above the IP in the
protocol stack and which has passed the Datagram on to the IP.
Usually the upper layer protocol is TCP (6) or, as we shall see later, UDP (17). Other well-
known options include: ICMP (1) and SMP (121).
Header Checksum
This 16-bit checksum checks the integrity of the complete IP header. The originating host
applies the checksum and all routers check the header for integrity. Because the TTL field
would have been changed by the router, a new checksum must be generated when the
Datagram is resent. Finally, the checksum is again reconfirmed by the receiving host.
Because the IP provides an unreliable service, this field only checks the header rather than
the entire packet.
Source/ Destination Address

These are the 32-bit Source and Destination IP addresses included in the header. These are
not MAC addresses.
Options
A set of options that may be applied to any given packet include sender-specified source
routing or security indication. The option list may use up to 40 octets (10 x 4-octet words).
The option fields must be at least 32-bits in length and must be padded to that amount if they
are shorter. If there are no options, this field is null.
IP addressing
The first question to ask might be, “Why do I need an IP address that is typically (e.g. IPv4)
limited to 32-bits when I have a more-than-adequate physical addressing scheme already
built into Ethernet?”
Variously known as the ‘MAC Address’, ‘Network Interface Card (NIC) Address’, and
‘Physical Address’, this 48-bit addressing scheme provide up to 248 = 2.8 x 1014 potential
addresses.
The problem is that whilst the MAC address caters for closed network systems (albeit very
large ones) it is not suitable for inter-networking. A message destined for a host on the
source network is easily identifiable. But if it’s on another network altogether, the task
becomes far more difficult. If we relied on the MAC address only, then when the message
is forwarded onto the Internet Service Provider (ISP), the ISP routers would need to have a
database of every single MAC address in the world – a clearly impossible task.
The use of the IP address, with its hierarchical structure, first defines the network itself and
only then the identity of the host on that network. The most common of these schemes,
IPv4, makes use of a 32-bit length header that provides, potentially, up to 232 (4 294 967
296) addresses.
Unfortunately, because portions of the IP address space had not been efficiently allocated and
the traditional model of addressing did not allow the address space to be used to its maximum
potential, there was a manifestly unfair distribution of addresses. For example, although
more than half of all possible IPv4 addresses were assigned to ISPs, corporations, and
government agencies, only an estimated 69 million addresses were actually in use. And as
the Internet continues to grow this finite number of addresses will be eventually exhausted.
Fortunately, the life of IPv4 has been considerably extended through the adoption of what
is termed a classless addressing scheme within that has allowed better management of the
IP addresses.
The long-term solution can be found in the widespread deployment of IP version 6 (IPv6)
that makes use of a vastly increased capacity 128-bit addressing scheme. Although scheduled
for introduction in 1998, IPv6 has been continually delayed and, to date, too few routers
have been adapted to recognize this format. Nonetheless, IPv6 is slowly being taken up and
as of late November 2012, IPv6 traffic share was reported to be approaching 1%.
At its inception the IP address space was divided into five classes: A, B, C, D and E. The
first three classes (A, B and C) were originally allocated on the base of the size (or clout) of
the organization. Thus, Class A addresses were reserve for large (mainly) government
organizations including the US Department of Defense); Class B were intended for large
corporations and ISPs (e.g. IBM, General Motors) and Class C for the ‘hoi polloi’ (the rest
of us).
Class D is used for multicasting and Class E is reserved for testing and experimentation.
Although the address is shown as a single 32-bit value, the format must include the class
identifier; the identity of the network (referred to as the ‘netid’) and the identity of the host
on the network to which the data is to be sent (referred to as the ‘hostid’).
Each class fixed the boundary between the network number and the host number at a
different point within the 32-bit address. A Class A address, for example, identified by the
prefix ‘0’, uses the first octet to identify the ‘netid’ and the remaining 3 octets to identify
the ‘hostid’. This means that the boundary point falls between the 7th and 8th bits (Figure
4.7).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Class A 0 ‘Netid’ ‘Hostid’
Class B 1 0 ‘Netid’ ‘Hostid’
Class C 1 1 0 ‘Netid’ ‘Hostid’
Class D 1 1 1 0 Multicast Address
Class E 1 1 1 1 0 Reserved for future
Figure 4.7. The class prefix fixes the boundary between the network number and the host
number at different points.
Similarly, a Class B address is identified by the prefix ‘10’ and uses the first two octets to
identify the ‘netid’ and the remaining 2 octets to identify the ‘hostid’. This means that the
boundary point falls between the 15th and 16th bits.
And finally, the Class C addresses are prefixed with ‘110’ and use the first three octets to
identify the ‘netid’ and the last octet to identify the ‘hostid’ – with the boundary point
falling between the 23rd and 24th bits.
Address notation
Suppose you are confronted with the following IP address:
10000101001101100101011110101010
How do you start to make sense of it? Well, the first thing is to split it up into octets to
make it a little more readable:
10000101 00110110 010101111 0101010
Since it starts with 10 it’s a Class B address and the ‘netid’ to ‘hostid’ split come after the
first octet as shown in Figure 4.8.
(10) 000101 00110110 01010111 10101010
Netid Hostid
Figure 4.8. Since the address starts with 10 it’s a Class B address and the ‘netid’ to
‘hostid’ split come after the first octet.
This means that the ‘netid’ is 000101 00110110 and the ‘hostid’ is 01010111 10101010.
In order to assist us in with large strings of binary numbers, each of the four octets is
converted to decimal. Thus:
100010101 00110110 010101111 0101010
Becomes:
138 54 175 42
and is written:
138.54.175.42
This notation is referred to as dotted decimal notation.
Masking
We’ve already seen that the class prefixes are used by the processor to determine the break
between the ‘netid’ and the ‘hostid’.
Thus a Class A prefix of ‘0’ lets us know that the boundary point falls between the 7th and
8th bits; a Class B prefix of ‘10’ lets us know that the boundary point falls between the 15th
and 16th bits; and a Class C prefix of ‘110’ indicates the boundary point falling between the
23rd and 24th bits.
A somewhat simpler method is to make use of Masking (sometimes referred to as Net

Masking) in which we enter a ‘1’ for each bit which is part of the ‘netid’ and a ‘0’ for each
bit which part is the ‘hostid’.
Net Masking for a Class A system is shown in Figure 4.9 together with its decimal and
decimal dotted equivalents.
Class A
Mask 11111111 00000000 00000000 00000000
Figure 4.9. Net Masking for a
‘netid’ ‘hostid’ Class A system together with its
decimal and decimal dotted
Decimal 255 0 0 0 equivalents.
‘netid’ ‘hostid’
Decimal Dotted 255.0.0.0
Subnetting
Clearly, a Class A address with nearly 17 million hosts on a single network was totally
unmanageable. The volume of traffic alone would render the network ineffectual.
Similarly, even a Class B address with only (?) 65 534 hosts per network is equally
unmanageable.
The solution lies with subnetting that allows a single Class A, B, or C network to be divided
into number of smaller sections. Instead of the normal two-level hierarchy, subnetting
supports a three-level hierarchy that creates additional network IDs at the expense of host
IDs. Figure 4.10 shows the basic concept of subnetting, which is to divide the standard
‘hostid’ field into two parts – the ‘subnetid’ number and the ‘hostid’. In other words we steal
bits from ‘hostid’ and use them for a ‘subnet’ number. Thus instead of:
‘netid’ + ‘hostid’
the IP address is now:
‘netid’ + ‘subnetid’ + ‘hostid’
‘netid’
Figure 4.10. Subnetting
192 100 100 involves dividing the standard
address ‘hostid’ field into two
parts – the ‘subnet’ number
and the ‘hostid’. This example
0 0 0
shows a Class C address.
1 1 1
‘subnetid’ ‘hostid’
Let’s assume an organization wishes to split its structure into for separate entities, each with
its own network: e.g. marketing, manufacturing, administration, and accounts.
The first question is how many bits do we need to steal? Let’s see how many networks we
can identify using two bits. As we see in Table 4.1 it’s only two because we can’t use all ‘1’s
or all ‘0’s.
Table 4.1. A two-bit subnet identifier only

allows us to identify two subnets since we can’t
use all ‘1’s or all ‘0’s.
Subnet ID Use for:
number
00 Not allowed
01 Subnet 1
10 Subnet 2
11 Not allowed
Following this argument the requirement for four subnets would require 3 bits (Table 4.2).
This in fact caters for up to six subnets and if we only create four, we shall see that this is
wasteful.
Table 4.2. A three-bit subnet identifier

allows us to identify 6 subnets.
Subnet ID Use for:

number
000 Not allowed
001 Subnet 1
010 Subnet 2
011 Subnet 3
100 Subnet 4
101 Subnet 5
110 Subnet 6
111 Not allowed
It follows that the number of subnets we can create is given by:
Number of subnets = 2x -2
where x is the number of bits. This is shown in Table 4.3.
Table 4.3. The number of bits required to create a

given number of subnets.
Number of Number of
bits Subnets
2
3 6
4 14
5 30
6 62
7 126
8 254
9 510
10 1022
Let’s go back to our requirement for four subnetworks. The problem is, of course, that every
bit ‘stolen’ for use in subnetting, reduces the ‘hostid’ by one. Thus in our example above
where we’re required to set up four subnetworks using three bits, this only leaves 5 bits out of
the octet for the actual ‘hostid’ (Figure 4.11).
‘netid’
Figure 4.11. Subnetting involves
192 100 100 dividing the standard address ‘hostid’
field into two parts – the ‘subnet’
number and the ‘hostid’. This example
shows a Class C address.
0 0 0 0 1 (110)
1 1 1 1 0 (3010)
‘subnetid’ ‘hostid’
Again it follows that the number of ‘hostids’ we can create is given by:
Number of ‘hostids’ = 2x -2
Which, in this case where we have only five bits =30.
Now we can see why subnetting can be inefficient. Without subnetting a Class C address
system catered for up to 254 ‘hostids’. With six subnets (the maximum allowed) we’ve
reduced the total number of ‘hostids’ from 254 down to:
6 x 30 = 180
And if we only use four of the available six, we’ve reduced the total number of ‘hostids’ from
254 down to:
4 x 30 = 120
So, although subnetting is essential in Class A and B networks, it is not very efficient in
terms of ‘hostid’ allocation.
Subnet Masking
In order to implement subnetting we make use of subnet masking in which the mask is
extended to cover the bits used for the ‘subnetid’. In our example where we’ve make use of 3
bits for the ‘subnetid’ and thus the subnet mask would be extended to cover them (Figure
4.12).
‘subnet’ mask
Subnet mask 11111111 11111111 11111111 11100000
Decimal 255 255 255 224
Decimal Dotted 255.255.255.224
Figure 4.12. In subnet masking the mask is extended to cover the bits used for the
‘subnetid’.
Classless addressing
We have seen earlier that because Internet addresses were only assigned in three sizes, there
were a lot of wasted addresses. Indeed, while the Internet was running out of unassigned
addresses, only 3% of the assigned addresses were actually being used.
To alleviate this problem, a new addressing scheme was introduced called Classless Inter-
Domain Routing (CIDR).
As the name implies, classless addressing completely eliminates the prior notions of classes.
Instead of the traditional Class A, B, and C network addresses, CIDR and replaces them with
a network prefix that allows Internet blocks to be arbitrarily sized networks rather than the
standard 8-bit, 16-bit, or 24-bit network numbers associated with ‘classful’ addressing.
In the CIDR model, a subnet bit mask (or prefix length) is used to show where the line is
drawn between the network ID and the host ID. In the example shown in Figure 4.13 the
network is thus specified as 186 . 65 . 152 . 0/22. The ‘22’ shows that the ‘netid’ is 22 bits
long and the ‘hostid’ is 10 bits in length – thus catering for 1022 hosts (210 – 2).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 8 16 22 24 32
Classless Network
186 65 152 0 186.65.152.0/22
22 bits for ‘netid’

10111010 10000001 1001100000000000 10 bits for ‘hostid’
Subnet Mask for /22

11111111 11111111 1111110000000000 network
Subnet Mask in
255 255 252 0 Dotted Decimal
Figure 4.13. In the network specified as 186 . 65 . 152 . 0/22, the ‘22’ shows that the ‘netid’
is 22 bits long and the ‘hostid’ is 10 bits in length.
This is termed CIDR notation (otherwise known as slash notation). The IP address
advertised with this /22 prefix could be a former Class A, B, or C address. Routers that
support CIDR do not make assumptions based on the first three bits of the address but rely on
the prefix length information provided with the route.
CIDR currently uses prefixes ranging from 13 to 27 bits (Table 4.4). Thus, blocks of
addresses can be assigned to networks as small as 32 hosts or to those with over 500 000
hosts. This cater for address assignments that much more closely fit an organization's specific
needs.
Table 4.4. CIDR prefixes
CIDR block Number of

prefix host addresses
/27 30 hosts
/26 62 hosts
/25 126 hosts
/24 254 hosts
/23 510 hosts
/22 1022 hosts
/21 2046 hosts
/20 4094 hosts
/19 8190 hosts
18 16 382 hosts
/17 32 766 hosts
/16 65 534 hosts
/15 131 070 hosts
/14 262 142 hosts
/13 524 286 hosts
Address Resolution Protocol (ARP)

Sitting at the same level (the Internet Layer) as the IP (Figure 4.1) is the Address
Resolution Protocol (ARP).
Networking hardware such as switches, hubs, and bridges operate on Ethernet frames and,
therefore, make use of MAC addresses to communicate with each other – unaware of the
higher layer data carried by these frames. Consequently, when an incoming packet destined
for a host machine on a particular local area network arrives at a gateway, it needs to find a
MAC address that matches the IP address.
The role of the Address Resolution Protocol (ARP) is simply to translate the IP address to the
physical address of the destination host – using a lookup table called the ARP cache. If the
address is found, the datagram transmission proceeds. However, if the address is not found in
the ARP cache, a broadcast, called the ARP Request, is sent to all hosts on the local network.
This ARP Request includes the originator's IP and physical addresses as well as the requested
IP address.
If one of the host on the network recognizes its own IP address in the request, it sends an
ARP Reply back to the requesting host. The reply, containing the host MAC address and any
source routing information, is stored in the ARP cache of the requesting host. All subsequent
datagrams to this destination IP address can now be translated to a physical address, which is
used by the device driver to send out the datagram on the network.
Chapter 5. Transmission control
Protocol (TCP)
I f we examine the ARPA model of Figure 5.1 we see that at the level above the Internet
Protocol (IP) we have what is referred to as the ‘host-to-host’ layer (equivalent to the
‘Transport Layer’ in the OSI Model) – made up of either the Transmission Control
Protocol (TCP) or User Datagram Protocol (UDP).
OSI MODEL ARPA MODEL
7. APPLICATION
SNMP
FTP SMTP TFTP DNS
(Simple PROCESS AND
TELNET (File (Simple Mail (Trivial File (Domain
6. PRESENTATION Network APPLICATION 4.
Protocol Transfer Transfer Transfer Name
Management LAYER
Protocol) Protocol) Protocol) Service)
Protocol)
5. SESSION
TCP UDP SERVICE OR

4. TRANSPORT (Transmission Control (User Datagram HOST-TO-HOST 3.
Protocol) Protocol) LAYER
ARP ICMP
IP INTERNET
3. NETWORK (Address Resolution (Internet Control 2.
(Internet Protocol) LAYER
Protocol) Message Protocol)
2. DATA LINK Network interface card: Ethernet; Token Ring; ARCNET; etc
NETWORK
INTERFACE 1.
LAYER
1. PHYSICAL Transmission media: coaxial cable; twisted pair; fibre optics; wireless; etc
Figure 5.1. The ‘host-to-host’ layer of the ARPA Model sits above the Internet Protocol
(IP) and is made up of either the Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP).
We have seen in Chapter 4 that the Internet protocol (IP) provides a means of addressing
source and destination hosts; providing a routing facility; and in providing a fragmentation
and reassembly service. However, IP is termed an ‘unreliable’ service in that when packets
are forwarded to a host there is no automatic mechanism for acknowledgement. We’ve done
our best to get it off to the correct destination but once it’s sent, we just live in hope. We
really don’t know if the packages have arrived, or are in the correct sequence.
The TCP, on the other hand provides a ‘reliable’ host-to-host communication service.
Encapsulated within the IP it provides a common interface to the application layer. Whereas
the IP protocol deals only with packets, TCP enables two hosts to establish a connection and
exchange streams of data. TCP also guarantees delivery of data and that packets will be
delivered in the same order in which they were sent. Further, whilst IP plus MAC addressing
schemes deliver data to the correct host, one of the most important attributes of TCP is that it
delivers directly to the application process software on the relevant machine. This is
performed by through the use of port numbers that are associated with particular
applications.
TCP header
TCP segments are constructed from 32-bit words and include a 20-octet (5 word) header
(Figure 5.2).
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Source Port Number Destination Port Number
Sequence Number
Acknowledgement Number
U A P P S F
Header
Reserved R C S S Y I Window size
length
G K H T N N
Checksum Urgent Pointer
Options
Padding
Data
Figure 5.2. TCP segments are constructed from 32-bit words and include a 20-octet (5
word) header.
As can be seen, TCP offers a number of basic services:

 associating port numbers with specific applications
 associating a sequence number with every octet in the data stream
 wrapping higher level application data in segments
 wrapping the segments into IP datagrams
 exchanging special segments to start up and close down a data flow between two hosts
 using acknowledgments and timeouts to ensure the integrity of the data flow
A brief description of each field is given below. A more detailed discussion will be given
later.
Source/destination port numbers

The source (and destination) port numbers allow TCP to deliver the data directly to the
application process software on the relevant machine.
Sequence Number
This 32-bit number identifies the first octet of the data in the segment.
Acknowledgment number
This 32-bit number is the octet number of the next octet that the sender expects to receive
from the remote host. The remote host can infer that all octets up to this number minus one
have been safely received and the remote host's local copies can be discarded.
Header length
This 4-bit field specifies the header length in 32 bit words. Clearly the maximum value is 15
words (60 octets) allowing for 10 (40 octets) of options.
Flag bits
This group of 6 bits (Table 5.1) identify various special states in the protocol. Several of the
bits may be set simultaneously. The bits are discussed in more detail later.
Table 5.1. Flag bits identify various special states in the protocol.
Window Description
URG Indicates that the Urgent Pointer Field is valid.
ACK Acknowledgment Number is valid.
PSH This segment requires a ‘push’.
RST Reset the connection.
SYN Synchronize sequence numbers.
FIN The sender has finished sending data.
Window size
the space available (normally given in octets) for the storage of unacknowledged data. The
maximum value is 65535.
Checksum
This covers both the header and the data and is calculated by attaching a pseudo-header to
the TCP segment, this consists of 3 x 32-bit words (12 octets) that contain the source and
destination IP addresses, a octet set to 0, a octet set to 6 (the protocol number for TCP in an
IP datagram header) and the segment length (in words). It should be stressed that the pseudo-
header is only used for purposes of calculation and is not actually transmitted.
Urgent pointer
This is part of TCP's mechanism for sending urgent data that is placed at the beginning of a
frame. If the URG flag bit is set this field indicates the position within the data of the last
octet of the urgent data.
Options
A number of options are available including the Maximum Segment Size (MSS) specification
facility.
Ports
Arguably one of the most important features of TCP is the concept of ports. The
communication process between the Transport layer and the Application layer involves
identifying the application that has requested a transport mechanism. The role of ports is to
identify to which process on the machine data should be sent for further processing and thus
port numbers allow TCP to deliver the data directly to the application process software on the
relevant machine.
Port identities are specified by a 16-bit number offering a range from 0 to 65 535. The port
numbers are controlled by IANA (the Internet Assigned Numbers Authority) and can be
divided into three groups:
Well Known Ports

These port numbers, in the range 0-1023, are assigned by IANA to the server side of an
application and are known globally to all TCP users – thus representing the ports to which
standard applications listen. Examples include:
21 = ftp (File Transfer Protocol (Control))

23 = telnet (TELNET)
25 = smtp (Simple Mail Transfer Protocol)
80 = www-http (World Wide Web HTTP)
161 = snmp (Simple Network Management Protocol)
502 = modbus (Modbus-TCP)*
*
See: Modbus-TCP’
Registered Ports
Port numbers in the range 1024-49151 are numbers that have been registered by IANA as a
convenience for the Internet community to avoid vendor conflicts. Server or client
applications can use the port numbers in this range. Examples include port numbers
registered for Microsoft Windows or for specific types of PLCs.
Dynamic Ports
The remaining port numbers, in the range 49152-65535, are called Dynamic, Private or
Ephemeral Ports and can be used freely by any client or server on an informal, ad-hoc basis.
Flow control
We saw earlier that TCP is referred to as a ‘reliable’ connection service. This is because TCP
establishes a connection between two host before any data is transmitted, This means that it is
possible to verify the receipt of packaged at either end and to arrange for retransmission in
the event of non-delivery due to lost or damaged packages.
In order to perform these tasks, TCP makes use of a variety of built-in elements:
Sockets
The overall identification of an application process actually uses the combination of the IP
address of the host it runs on and the port number which has been assigned to it. This
combined address is called a socket. Sockets are specified using the following notation:
<IP Address>:<Port Number>
So, for example, if we have a Web site running on IP address 138.54.175.42, the socket
corresponding to the HTTP server for that site would be 138.54.175.42:80.
Sequence Number
We saw earlier in Chapter 15 that each IP Datagram sent by a host is identified by a unique
16-bit number that is normally incremented by one, each time a Datagram is sent.
Instead of sequencing each datagram, TCP sequences each octet in the segment. The first
data octet in the segment is given an ‘arbitrary’ initial 32-bit Sequence Number. It is this
Sequence Number of the first octet that is included in the TCP header. Each successive octet
is incremented by one so that successive packets of the data stream have ascending Sequence
Numbers. However, these numbers are not actually sent but are only incremented by the
receiver in order to keep track of the number of octets. Thus if there are 480 octets of data in
each packet, the first packet might be numbered 0, the second 480, the next 960, the next
1440, etc. In order to prevent a packet with a Sequence Number from an earlier connection
arriving late and being mistaken for a Sequence Number from a current segment, the
sequence numbering cannot start at zero each time. Accordingly, the Sequence Number is
generated by a 32-bit clock generator that is initiated during boot-up and is incremented by
one approximately every 4 µs. When a connection is established the generator value is read
into the TCP header as a ‘random’ initial Sequence Number.
With an increment every 4 s the initial Sequence Number will wrap in about 4¾ hours
which should be more than sufficient time to prevent delayed segments from a previous
connection getting mixed up with a new connection.
Acknowledgement Number
Assume two hosts, A and B (Figure 5.3). When a connection is being established, the
initiating host (host A) reads a value (assume, as an example, a random number of 123) out of
its Sequence Number counter and inserts it into the Sequence Number field . The TCP
header is then transmitted, without data, with the SYN flag set to ‘1’ – signaling that a
connection is being established .
Sequence
Counter Host Host
Host A A TCP Header 1 B
Initial Sequence Number = 123
123 1 123 SYN flag = 1 2 123
TCP Header 2
Acknowledgement = 124 123+1 Sequence
ACK flag = 1 4 3 Counter
Host B
5
Initial Sequence Number = 345
SYN flag = 1 6 345
345
TCP Header 3
Acknowledgement = 346 7
Figure 5.3. Establishing a connection between two hosts A and B.
On receipt of the transmission, the receiving host (B) responds by incrementing the Sequence
Number by one (to 124) and sending it back to the originating host as an
Acknowledgement. It also sets the ACK flag to ‘1’ to indicate that this is an
acknowledgement.
At the same time, Host B has also read a random number value out of its Sequence Number
counter (assume, as an example, 345) and inserted it into the Sequence Number field . This
frame, that now includes both a Sequence Number and an Acknowledgement, is sent back to
the originating host (A) – again with its SYN set at ‘1’ .
On receipt of this ‘composite frame, Host A (the originator) notes that its own request for a
connection has been complied with, increments the received Sequence Number by one and
sends it back to Host B as an Acknowledgment (346) . Once this two-way ‘full duplex’
communication has been established, data is now sent from Host A to Host B – with Host B
incrementing Sequence Numbers and Host B Acknowledging them. These connections
remain established until terminated.
From the foregoing it can be seen that during the connection phase, the Sequence Numbers
for both hosts are set up independently and that, therefore, the Sequence Number and the
Acknowledgment in any one header bear no relationship to each other.
Sliding window
From the foregoing we can see that once a connection is established each packet needs to be
acknowledged, within a given time, to ensure a guaranteed delivery. To this effect, the
transmitting host starts a timer so that if no response is received from the destination host
within a given time, the message will be retransmitted. However, if the originating host had
to wait for each individual acknowledgment to be returned before sending the next one then,
because of delays in the Round Trip Time (RTT), this would clearly be very time consuming
and inefficient.
This problem is overcome through the use of a sliding window that allows a transmitting host
to send the data in a stream without having to wait for an acknowledgement for every single
packet.
The size of the window determines the maximum number of unacknowledged octets that are
allowed in any one transmission sequence.
By default Windows uses 8760 octets for Ethernet – although this can be changed in the
registry. This allows 6 x full Ethernet data frames of 1460 octets to be sent without
acknowledgment.
Generally, a window of 6 - 8 times the packet size is considered the most efficient. When
protocols such as X.25 were prevalent users were often advised to assume a much smaller
datagram size of 576 octets. As a result users may come across smaller window size settings.
User Datagram Protocol (UDP)

One of the major benefits of TCP is that it offers a connection – based ‘reliable’ host-to-host
communication service – enabling two hosts to establish a connection and exchange streams
of data. TCP also guarantees delivery of data and that packets will be delivered in the same
order in which they were sent. However, all these built-in functions and benefits come at the
cost of significantly larger additional overheads in terms of processing time and header size.
Not only that, but in many control networks, a ‘reliable’ connection is accomplished at the
Application layer. In such cases we can make use of a very much abbreviated form of the
TCP called the User Datagram Protocol (UDP).
The UDP header, as shown in Figure 5.4, only requires eight octets and its only real
contribution is the assignment of the Source and Destination port numbers for use by the
Application layer.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Source Port Number Destination Port Number
Window size Checksum
Data
Figure 5.4. UDP header only requires eight octets and its only real contribution is the
assignment of the Source and Destination port numbers for use by the Application layer.
As can be clearly seen, UDP is not concerned with acknowledging message receipt, correctly
ordering received packets into meaningful messages, discarding duplicate packets or
requesting retransmission of faulty packets. And if the application layer is designed to
provide this reliability of service there is no reason to duplicate this effort. Consequently
UDP with its low overhead and rapid execution makes it very attractive for control networks.
Modbus-TCP
Serial communication via RS-232/485 Modbus interfaces has been widely used throughout
the industry for many years – with over 300 different interface devices available on the
market.
In recent years this unsung hero(ine) of the Fieldbus world has been given a new lease of life
in the form of Modbus-TCP. Modbus-TCP not only allows Modbus to run on Ethernet at
rates up to 100 Mbps but also makes use of TCP’s guaranteed delivery mechanism.
Modbus application protocol

The application protocol is independent of the data transmission medium and is organised
according to the client/server principle. The client sends a ‘request telegram’ calling for
services and the server replies with a ‘response telegram’. The essential differences between
the standard Modbus telegram and that of Modbus-TCP (Figure 5.5) is that with standard
Modbus the slave address, function code, data and CRC error check fields are sent as a
complete frame whereas in Modbus-TCP, the addressing and error checking is handled by the
underlying TCP protocol.
Modbus frame running under RS 232/485
Destination Function CRC error

Data
Address Code check
TCP Header Application Data
IP Header TCP Header Application Data Modbus running

under TCP/IP
Ethernet Ethernet
IP Header TCP Header Application Data
Header Trailer
Figure 5.5. Essential differences between the standard Modbus telegram and Modbus-
TCP.
As shown, Modbus-TCP uses the TCP for data transmission of the Modbus application
protocol – with the parameters and data are encapsulated within the user data container of a
TCP telegram.
Although the efficiency of Modbus-TCP is relatively high, at approximately 60%, in practice,

the data transport rate is much lower because data transmission delays in the network limit
the overall performance. According to one source (Michael Volz, ‘Modbus-TCP: The quiet
success story’ Control Engineering, Europe June 1, 2003) tests with a Momentum PLC
showed that it was possible to service about 4 000 remote I/O devices per second, each with
32 digital I/Os and 16 analogue values – roughly corresponding to the data transmission
performance of a Profibus-DP System at 1.5 Mbps.
Chapter 6. DNP3
D NP3 (Distributed Network Protocol Version 3) is an open, intelligent, robust, and

efficient modern SCADA protocol designed to optimise the transmission of data
acquisition information and control commands.
Originally created by a Westronic, Inc. (Now GE Harris) in 1990, the protocol was released
into the public domain in 1993. Full ownership was given over to the DNP Users Group later
that year – making it a truly ‘open’ and non-proprietary protocol.
Designed specifically for the power generation industry DNP3 is designed to create open,
standards-based interoperability between a substation computers, RTUs, IEDs (Intelligent
Electronic Devices) and master stations. The byte efficiency of DNP3 makes it a particularly
good choice for bandwidth-constrained applications in distribution systems like pole-top
devices.
Features of the DNP3

DNP3 offers a flexibility, robustness, and functionality that go far beyond conventional
communication protocols. Because DNP is an object-based application layer protocol, it has
the flexibility to support multiple operating modes such as poll-response, polled report-by-
exception, unsolicited responses, and peer-to-peer. Amongst its features, DNP3 includes:
 allows addressing of over 65 000 devices on a single link
 open protocol
 classification of field data
 time-stamped data
 support for time synchronization
 secure authentication
 diagnostic information for each I/O point
 satisfies the need for multiple masters and (limited) peer-to-peer operations
 caters for user-definable objects – including file transfer
 segments messages into multiple frames to ensure exceptional error detection and
recovery
 request and respond with multiple data types in single messages
 includes only changed data in response messages
 assigns priorities to data items
 provides data link and application layer confirmation
 multiple reporting modes:
 Polled only.
 Polled report-by-exception.
 Unsolicited report-by-exception (quiescent mode)
Chapter 6. DNP3 52
Basic topology
DNP3 is typically used to communicate between centrally located Master stations and
distributed remote stations called Outstations. In essence the Master serves as the control
centre and typically comprises a SCADA with HMI network interface whilst the Outstation
interfaces to the physical devices being monitored and or controlled – usually comprising
Remote Terminal Units (RTUs) communicating with Intelligent Electronic Devices (IEDs).
As illustrated in Figure 2.1, both the Master and the Outstation make use of a library of
common objects to exchange information.
Figure 2.1. DNP3 typically communicates between centrally located Master stations and
distributed remote stations called Outstations – using a library of common objects to
exchange information.
Figure 2.1 illustrates what is termed a ‘One-on-one’ topology. However, DNP3 also caters for
a multiplicity of topologies including ‘Multi-drop’ and a variety of ‘Hierarchical’ schemes
(Figure 2.2).
DNP3 DNP3 DNP3 DNP3 DNP3 DNP3

Outstation
DNP3
Master Outstation Outstation Outstation Master DNP3 Master
Outstation
Multi-drop Hierarchical
Figure 2.2 DNP3 also caters for a multiplicity of topologies including ‘Multi-drop’ and a
variety of ‘Hierarchical’ schemes.
The OSI/ISO model

DNP3 is a layered protocol – loosely based on the OSI/ISO model. The OSI model
characterises data communications into seven hierarchical layers – each having a defined
purpose and each interfacing directly with the layer above it and below it.
Figure 2.3 shows how information on the source device (e.g. computer) travels down through
each layer, across the network media, and back up through the layers on the destination
computer.
Chapter 6. DNP3 53
Source device Destination device

Layer 7 Application Application
Layer 6 Presentation Presentation
Layer 5 Session Session
Layer 4 Transport Transport
Layer 3 Network Network
Layer 2 Data Link Data Link
Layer 1 Physical Physical
Figure 2.3. Information on the source device travels down through each layer,
across the network media, and back up through the layers on the destination
computer.
At the transmitting site, as the information passes down through the seven layers, each layer
(with the exception of the lowest) adds headers (and possibly trailers) to call up functions in
accordance with the protocol rules of each layer (Figure 2.4). It should also be appreciated
that these headers and trailers, used to provide control information, considerably add to the
overhead of each frame and reduce the total available bandwidth of the network.
AH Application
PH AH Presentation
SH PH AH Session
TH SH PH AH Transport
NH TH SH PH AH Network NT
DLH NH TH SH PH AH Data Link NT DLH
Pre DLH NH TH SH PH AH Physical NT DLH Post
Figure 2.4. Each layer adds headers (and possibly trailers) to call up functions in
accordance with the protocol rules.
Chapter 6. DNP3 54
Reduced OSI model

One problem with implementing the full seven-layer OSI model, particularly when used in
industrial applications, is the large overhead that the data acquires as it passes down the stack
from the application layer. In industrial networks, time is generally critical. Because each
layer carries its own header and footer, huge amounts of time can be wasted in the form of
hundreds of bytes of header/footer information for, possibly, eight bytes of relevant
information. Consequently, the use of or seven layers is not usually appropriate for real-time
communications. Subsequently, in applications where time-critical communication is more
important than the ‘academic’ implementation of the full seven layer protocol, a simplified
OSI model is often preferred where, in the interests of efficiency, the seven-layer OSI stack is
collapsed. As a result, most industrial protocols are written around only the Application
Layer; the Data Link Layer; and the Physical Layer.
The IEC refers to this reduced OSI model as the Enhanced Performance Architecture (EPA).
In DNP3 use is made of an enhanced version of the EPA by adding a fourth layer – a
pseudo-transport layer that allows for message segmentation. This is shown in Figure 2.5.
Master Outstation
DNP3 User’s Code DNP3 User’s Code

DNP3 DNP3
Application Layer Application Layer
Pseudo Transport Layer Pseudo Transport Layer
DNP3 DNP3
Data Link Layer Data Link Layer
DNP3 DNP3
Physical Layer Physical Layer
Physical media
User requests
User responses
Figure 2.5. DNP3 enhanced version of the Enhanced Performance Architecture

(EPA) – based on the reduced OSI model .
DNP3 Application Layer

The DNP3 Application Layer provides standardised functions and data formatting and allows
the User Layer above it to gain access to the network.
DNP3 Pseudo-Transport Layer

In DNP3 the Pseudo-Transport Layer, comprising a single byte, is incorporated into the
Application Layer and, when transmitting, is responsible for segmenting the application layer
messages into multiple frames – suitably sized for transmission by the Data Link Layer.
When receiving, the role of the Pseudo-Transport Layer is to reassemble the frames into a
longer Application Layer messages.
Chapter 6. DNP3 55
DNP3 Data Link Layer

The data link layer determines how the data is packed into a data frames and, using error
correction and detection techniques, ensures the link is reliable. The data link layer is also
responsible for handling information and acknowledgements and for determining which
nodes can transmit on the network at any given time.
DNP3 makes use of the FT3 frame format – considered the most reliable of the IEC 6870-5
recommended frame formats. However, whilst the FT3 IEC specification calls for
synchronous transmission, DNP3 is configured for asynchronous transmission with a variable
length frame. In addition, DNP3 makes use of balanced mode transmission and specifies a
collision avoidance scheme for multi-drop networks.
DNP3 Physical Layer

The physical layer defines the physical characteristics of the adapter interface and includes:
the format for the electrical signals (e.g. voltage and current levels); the encoding scheme;
synchronisation across the media (starting and stopping); the type of connector; and the
connector pin-out. The cable itself is not included in this level since the OSI model defines
only the communication properties of a node in a network and not the network itself.
Originally, DNP3 was specified over a simple serial physical medium such as RS-232, RS-
422and RS-485. However, most modern applications are implemented over Ethernet
(TCP/IP).
DNP3 packet structure overview

Figure 2.6 shows a more detailed view of the DNP3 packet structure and, without any doubt,
the packet structure is extremely complex.
Application data
Application Object Type (1) Variation (1) Index size (4 bits) Qualifier (4 bits) Application data
Application Control (1) Function Code (1) Internal info (2)

Application Control (1) Function Code (1)
Application Protocol Control Info (APCI) Application Service Data Unit (ASDU)
APDU fragment size limit 2018 bytes Application Protocol Data Unit (APDU)
Pseudo-Transport
TPDU size limit 250
Transport control (1) APDU Segment (249) Transport control (1) APDU Segment (249)
bytes to fit into Data
Link Frame
Data Link Frame size limit 292 bytes to fit

into Data Link Frame
Sync (2) Length (1) Control (1) Dest. Address (2) Source address (2) CRC (2) Transport frame
Physical
Physical media transmission: 8
bits; 1 Start bit; 1 Stop bit
Figure 2.6. An overview of the DNP3 packet structure

Chapter 6. DNP3 56
At the Application Layer, the Application Service Data Unit (ASDU), a packaged object in
itself, is combined with an Application Protocol Control Info (APCI) block to form what is
termed an Application Protocol Data Unit (APDU).
At the next layer down, the Pseudo-Transport Layer (which in reality forms part of the
Application Layer) is responsible for segmenting the APDU into 250-byte frames allowing it
to fit into Data Link Frame.
The Data Link frame comprises a fixed-length header block of 10 bytes (including two bytes
of CRC) followed by a maximum of 16 data blocks – with each incorporating its own 16-bit
CRC. The maximum frame length is 292 bytes.
And finally, at the Physical level, the complete ensemble is transmitted asynchronously and
simply comprises 8 data bits – together with a Start and Stop bit – but with no parity.
If conventional serial communication (RS 232/422/485) is used, the packet assembly is

completed and placed on the transport media (usually open wire twisted pair cable).
However, if the packet is to be sent over Ethernet, the three DNP3 layers are encapsulated in
the application layer; the assembled packet is, in turn, encapsulated in the Transport Control
Protocol (TCP); which, again in turn, is encapsulated in the Internet Protocol (IP). The User
Datagram Protocol (UDP) can also be used but presents some additional issues related to
reliable delivery in congested networks.
DNP3 Data Link layer

A key feature of DNP3 is its reliability – allowing it to be used, with relative impunity, in
electrically noisy environments. Error checking, therefore, is a prime consideration. In order
to examine this a little closer we need to look at the message structure at the Data Link level.
At the level of the Data Link Layer the DNP3 FT3 frame (Figure 2.7) comprises a fixed-
length header block followed by a number of data blocks – with each incorporating its own
16-bit CRC.
Maximum DNP3 frame length (292 bytes)
Header (10 bytes) Data payload

Control
Length
Sync Destination Source CRC User Data CRC User Data CRC
1 byte 1 byte 1 byte 1 byte 2 bytes 2 bytes 2 bytes 1 - 16 bytes 2 bytes 1 - 16 bytes 2 bytes
Data block 0 Data block n
Figure 2.7. The Data Link Layer FT3 frame comprises a fixed-length header block
followed by a number of data blocks – with each incorporating its own 16-bit CRC.
Chapter 6. DNP3 57
SYNC (2 bytes): although referred to as SYNC, the reality is that since the frame is
asynchronous it actually functions as a START field.
LENGTH (1 byte): specifies the total number of bytes in the frame – excluding the
START, LENGTH, and CRC fields. The minimum value for this field is thus 5 (no
data payload) and the maximum value is 255.
CONTROL (1byte): the 8 bits comprising the control field gives details of the frame
transmission direction; the type of frame; and flow control information according to
the details shown in Figure 2.8.
DIR PRM FCB FCV Function code
Bit 7 6 5 4 3 2 1 0
Identifies type of frame

Frame Count Bit valid
Frame Count Bit
Primary Message
1 = frame from primary (initiating station)
0 = frame from the secondary (responding station)
Physical transmission direction
1 = station A to station B
0 = station B to station A
Figure 2.8. Details of the 8 bits comprising the 1-byte Control field.
As indicated, the function code (bits 0, 1, 2, and 3) identifies the type of frame according to
Table 2.1.
Table 2.1. Function code (bits 0, 1, 2, and 3) identifies the type of frame.
PRM = 1
Function Frame type Service function FCV
code bit
0 SEND - CONFIRM expected RESET of remote link 0
1 SEND - CONFIRM expected Reset of user process 0
2 SEND - CONFIRM expected TEST function for link 1
3 SEND - CONFIRM expected User Data 1
4 SEND - NO REPLY expected Unconfirmed User Data 0
9 REQUEST - RESPOND expected REQUEST LINK STATUS 0
Secondary PRM = 0
Function Frame type Service function
code
0 CONFIRM ACK – positive acknowledgement
1 CONFIRM NACK – message not accepted, Link
busy
11 RESPOND Status of link (DFC = 0 or 1)
Chapter 6. DNP3 58
Destination address: specifies the address of the station that the frame is directed to.
The address 0xFFFF is an all-stations address.
Source address: specifies the address of the station that the frame originated from.
Header CRC: a 2-byte Cyclic Redundancy Check.
User data block: each data block may contain from 1 to 16 bytes of user data. Each
user data block has its own 2-byte CRC.
Message flow
Figure 2.9 illustrates some of the possibilities for message flow.
. DNP3 DNP3
Master Outstation
Accept request and

Case 1 Send request process
Optional confirmation
Accept response Send response
Send unsolicited
Accept response
Case 2 response
Figure 2.9. Examples of message flow between Master and Outstation.
In Case 1, the Master sends a request to the Outstation. The Outstation accepts the request
and processes it. The Outstation may, or may not, send an optional confirmation. The
Outstation sends a response to its action that is accepted by the Master. The Master may, or
may not, send an optional confirmation.
In Case 2 the Outstation sends an unsolicited response to the Master that is accepted. The
Master may, or may not, send an optional confirmation.
As we saw earlier in Figure 2.6, the Transport Protocol Data Unit (TPDU) in the Pseudo-
Transport layer contains a 1-byte transport header (TH) in the frame that contains information
on the frame sequence. This guards against missing or misguided frames that can result in an
altered message. Details of the Transport Header are shown in Figure 2.10.
Chapter 6. DNP3 59
FIN FIR SEQUENCE
Bit 7 6 5 4 3 2 1 0
Checks that frames are being

received in the right sequence and
guards against missing frames
Indicates first frame of the sequence

1 = first frame of the sequence
0 = not the first frame of the sequence
Indicates final frame of the sequence
0 = more frames are to follow
1 = final frame of sequence
Figure 2.10. Details of the Transport Header – a 1-byte addition to the

TPDU.
Application Protocol Data Unit (APDU)

As shown in Figure 2.6, the Application Protocol Data Unit (APDU) comprises two sections:
the Application Protocol Control Information (APCI) and the Application Service Data Unit
(ASDU).
Application Protocol Control Information (APCI)

The role of the APCI is twofold: to provide Application Control for segmentation and
sequence control; and to provide Function Coding for flow control.
The nature of the response also determines the length of the APCI. As shown in Figure 2.11,
if appended as a Request Header the APCI comprises: 1 byte of Application Control followed
by 1 byte of Function Code. If it’s a Response Header, it comprises the two Application
Control and Function Code bytes to which is added a 2-byte Internal Indication Information
(IIN) coding.
Application Control (1) Function Code (1) Internal info (2)
Application Control (1) Function Code (1)
Figure 2.11. Overview of the Application Protocol Control Information (APCI).
Application control
Details of the1 byte of Application Control, which deals with fragmentation, are given in
Figure 2.12.
Chapter 6. DNP3 60
FIR FIN CON SEQUENCE
Bit 7 6 5 4 3 2 1 0
Indicates fragment number
Confirm on receipt
1 = send confirmation
0 = confirmation not needed
Indicates the final fragment
1 = final fragment
0 = intermediate fragment
Indicates first fragment of a complete application message

1= first fragment
0 = not a first fragment
Figure 2.12.Details of the 1-byte Application Control.
Function codes
DNP3 makes use of 27 basic function codes to exchange information between Masters and
Outstations. Some of the function codes enable a Master to request and receive status
information from an Outstation whilst others enable the Master to determine or adjust the
configurations of an Outstation. Table 2.2 details some of the more widely used function
codes.
Table 2.2. Some of the more widely used function codes.
Function FUNCTION Description

Code
0 CONFIRM Message fragment confirmation used
requests and responses.
1 READ Request specified objects. Respond
with objects requested that are
available.
2 WRITE Store requested objects in outstation
and respond with status of the
operation
3 SELECT Select control points but do not
operate. Respond with the status of
control points.
4 OPERATE Produce output action on selected
control points. Respond with status
of control points.
5 DIRECT OPERATE Select and operate specified control
points. Respond with status of
control points.
6 DIRECT OPERATE – Select and operate specified control
NACK points. Do not send any response.
125 RESPONSE Response to a selected message.
130 UNSOLICITED Unsolicited response that was not
MESSAGE prompted by request.
Chapter 6. DNP3 61
Internal Indication Information (IIN)

Appended only to a response header, the IIN is a 2-byte field – part of the response header
that follows the Function Code. Figure 2.13 shows details of the first and second bytes
respectively.
IIN (1)
Bit 7 6 5 4 3 2 1 0
Indicates to Master success
of a broadcasted message
Class I data available
Class 2 data available
Class 3 data available
Time sync required from Master
Some of the control points not accessible
Device trouble
Device restart
IIN (2)
Bit 7 6 5 4 3 2 1 0
Function code not implemented
Requested objects are unknown
Parameters are not a valid or are out of range
Event buffer has overflowed
Request understood but is already executing
Current configuration is corrupt
Reserved (currently always set 0)
Reserved (currently always set 0)
Figure 2.13. Details of the first and second bytes of the 2-byte IIN field.
Application Service Data Unit (ASDU).

As shown in Figure 2.14, the ASDU comprises the Application data to which is attached the
object header – a library of objects that are typically used in SCADA systems.
Application data
Object Type (1) Variation (1) Index size (4 bits) Qualifier (4 bits) Application data
Figure 2.14. Overview of the Application Service Data Unit (ASDU).

Chapter 6. DNP3 62
Object models
Typically, a SCADA system comprises a number of remote terminal units (RTUs) that
collect field data in a number of formats (digital, analog, change of state, etc.) and
connects back to a master station via a communication protocol e.g. DNP3. This allows
the master station to display the acquired data and allows the operator to perform
remote control tasks.
In order to access a specific I/O point via the RTU protocol the user would either
require a wiring diagram or a ‘tag database’ that described which I/O points were
connected to which specific functions (e.g. VT, CT, circuit breaker, etc.).
In DNP3 this problem is overcome through the use of a data object model that
automatically creates the ‘mapping’ between the I/O points and specific functions in the
substation.
In DNP3 standard data types are termed Object Groups and include:
 binary inputs;
 binary outputs;
 counters;
 analog inputs;
 analog outputs;
 time and date;
 class;
 file transfer objects;
 etc.
An ‘analog input’ object, for example, may be used to report characteristics that have a range
of values: a temperature may have a range from 200 to 400°C; a compressor outlet pressure
can vary from 8 to 10 bar. In addition, within each object group, object variations exist that
are typically used to indicate a different method of specifying data within the object group:
e.g. allowing for transfer of data as a 16-bit signed integer; a 32-bit signed integer; or as a 32-
bit floating point value.
Because not every event needs to be reported, the Object grouping also allows users to
classify their data into different groups called ‘Class’. Currently DNP3 supports four classes
of data – 0, 1, 2, and 3. Class 0 data is real-time data whilst Classes 1, 2 and 3 are reserved
for objects that require time stamp information (event data). Each class of data is
independent from the other and incorporates variation parameters that allow the user to select
the type of value, time, and diagnostic information to be recorded. Some examples are given
in Table 2.3.
Chapter 6. DNP3 63
Table 2.3. Various DNP3 objects and their different classifications – 0, 1, 2 and 3.
DNPAI0 IOPOINT_D Class 1, 32-bit analog input (variation 1)

AI Object, Class 1, Static Var. 1 (with flags), Event Var. 3
(with time)
DNPAI1 IOPOINT_D Class 2, 32-bit analog input without flag (variation 3)
AI Object, Class 2, Static Var. 3 (NO flags), Event Var. 1 (NO
time)
DNPAI2 IOPOINT_D Class 0, 32-bit analog input (variation 1)
DNPAO0 IOPOINT_D Class 0, 32-bit analog output status (variation 1)
Analog Output Object, Real Time Data Point (Class 0)
DNPBC0 IOPOINT_D Class 1, 32-bit binary counter (variation 1)
Binary Input Counter
DNPBI0 IOPOINT_B Class 1, Binary input with status (variation 2)
BI Object, Class 1, Static Var. 2 (diagnostic flags), Event Var.
2 (with time)
DNPBI1 IOPOINT_B Class 0, Single bit binary input (variation 1)
DNPBI2 IOPOINT_B Class 0, Single bit binary input (variation 1)
DNPBO0 IOPOINT_B Class 3, Binary output (variation 1)
BO Object, Class 3; Static Var. 1 (with flags); Event Var. 1
(NO time)
DNPFC0 IOPOINT_D Real Time Value (Class 0), Frozen Counter 1
DNPFC1 IOPOINT_D
In order to maximize the number of data points that can fit into a single data frame, the
DNP3 object data model is described in purely numerical terms – comprising three different
parts:
Object Number – specifies the type of data point e.g.
1 = Binary Input Static data point
2 = Binary Input Event data point
Variation Number – specifies which optional parameters would be present for a given data
point of a specific object number e.g.
1 = the data point included status
2 = the data point did not include status
Index Number – refers to a specific instance of a DNP object and variation e.g. if a device
supports 16 binary input static objects, the index number to access one of these would be 0-
15.
This economy of scale in describing the object models is particularly relevant in

meeting the low bandwidth requirements of DNP3.
Chapter 6. DNP3 64
Chapter 7. IEC 61850
P roviding a standardized framework for substation integration, the IEC 61850 protocol
was designed as a high-bandwidth communication channel running on Ethernet –
leverage ring modern computer and networking technology to maximise reliability and
performance.
However, the IEC 61850 goes far beyond being just a protocol standard – making use of a
comprehensive set of device and object-models using a descriptive ‘naming’ convention
rather than identifying data by storage location and through the use of custom-object numbers
and indexes. Through the use of a standardised substation System Configuration Language
(SCL) device configuration, and its role in the power system, maybe precisely defined using
XML files.
XML
XML (Extensible Markup Language) is a markup language, designed to carry data, that is
both human-readable and machine-readable.
Although XML focuses on documents, it is widely used for the representation of arbitrary
data structures in, for example, web services, and is the most common tool for data
transmission.
XML was created to structure, store, and transport information by wrapping it in tags. A
simple example is shown below:
<memo>
<to>Mick</to>
<from>Karen</from>
<heading>Deadline Reminder</heading>
<body>Deadline for copy is end of June!</body>
</note>
As clearly seen, this message is quite self-descriptive. It has information regarding the
‘sender’ and the ‘receiver’ together with a ‘heading’ and a message ‘body’.
The unique features and characteristics of the IEC 61850 protocol are so numerous that they
cannot be practically enumerating in a single chapter. Indeed, the full scope of the IEC 61850
is defined in a 10-part standard (Table 7.1) covering more than 1500 pages.
Table 7.1 Structure of the IEC 61850 standard
Part Title
number
1 Introduction and Overview
2 Glossary of terms
3 General Requirements
4 System and Project Management
5 Communication Requirements for Functions and Device Models
6 Configuration Description Language for Communication in
Electrical Substations Related to IEDs
7 Basic Communication Structure for Substation and Feeder
Equipment
7.1 – Principles and Models
7.2 – Abstract Communication Service Interface (ACSI)
7.3 – Common Data Classes (CDC)
7.4 – Compatible logical node classes and data classes
8 Specific Communication Service Mapping (SCSM)
8.1 – Mappings to MMS(ISO/IEC 9506 – Part 1 and Part 2) and to
ISO/IEC 8802-3
9 Specific Communication Service Mapping (SCSM)
9.1 – Sampled Values over Serial Unidirectional Multi-drop Point-to-
Point Link
9.2 – Sampled Values over ISO/IEC 8802-3
10 Conformance Testing
However, a few of the benefits of the IEC 61850 listed below:

 networkable throughout the power generation system
 open protocol
 high-availability
 multi-vendor interoperability
 guaranteed delivery times with time stamping
 high-speed IED to IED communication
 diagnostic information for each I/O point
 caters for user-definable objects – including file transfer
 standards based
 auto-configurable/configuration support
 support for Voltage and Current sampled data
Following an examination of the communication stack, and a closer look at both the GOOSE
and SV services, will also take in an overview of the role of MMS and IEC61850’s approach
to object modelling.
And finally, we’ll try and carry out a fairly objective comparison of DNP3 and IEC61850.
The communication stack and mapping

Unlike DNP3, which makes use of the reduced EPA version of the OSI model, Figure 7.1
shows how the IEC 61850 makes full use of the mainstream technology of the ISO/OSI
communication stack – comprising the Ethernet (Layers 1 and 2), TCP/IP (Layers 3 and 4)
and manufacturing messaging specification, MMS, (Layers 5 to 7).
As shown, the object model and its services are mapped to the MMS application layer (layer
7) whilst time-critical services, such as SV and GOOSE, are mapped directly to the Ethernet
Link Layer. This ensures that outgoing SV and GOOSE frames are marked as high priority
frames which are handled with priority within all participating IEDs.
Data Model (Data and services)
Figure 7.1. IEC 61850 makes full use
Client-Server GOOSE Sampled values of the ISO/OSI communication stack –
comprising the Ethernet (Layers 1 and
2), TCP/IP (Layers 3 and 4) and
Mapping manufacturing messaging
specification, MMS, (Layers 5 to 7).
7
ISO/OSI Stack Layer
6 MMS
Time critical services
5
4 TCP
3 IP
2 Ethernet Link Layer with priority tagging
1 Ethernet Physical Layer (100 Mbps)
Generic Object-Oriented System Event, (GOOSE)

Often touted as the major outcome of the IEC 61850 standard, GOOSE is sometimes claimed
to be the single scale-tipping factor in favour of its use.
An acronym for Generic Object-Oriented System Event, GOOSE is a service used for speedy
transmission of time-critical trip commands and interlocking information that includes status
changes, blockings, releases, or trips between IEDs (Intelligent Electronic Devices). Here the
needs are for standardised, high priority, high-speed, high reliability, and safe transmission.
Intended to replace direct relay-to-relay wiring, GOOSE combines very high speed
transmission (< 4ms) with very high reliability.
As shown in Figure 7.2, traditional protocols make use of acknowledgements (ACK) in

which the Sender starts a timer immediately after transmitting the data and waits for an ACK
response. If a timeout occurs the Sender retransmits the data. Unfortunately, in protection
applications this is far too slow and far too late.
Sender Receiver
Data
Timer Figure 7.2. In traditional protocols the Sender starts a

Ack
timer immediately after transmitting the data and waits for
an ACK response. If a timeout occurs the Sender
Data retransmits the data.
Timer
Retry data
The IEC 61850 adopts a different approach, based on the IEEE 802 ‘multicast’ addressing
scheme, in which GOOSE assumes that the first message will not get through – and the
message is thus always retransmitted (Figure 7.3).
Sender Receiver
Data
Figure 7.3. GOOSE assumes that the first message will

not get through – and the message is thus always
retransmitted.
Since the multicast messages are not confirmed, the messages must be repeated as long as the
reported state persists, in order to achieve a high level of reliability. Such an approach
depends on the receiver to detect duplicates – making use of filters to reject data that is not
needed.
Since GOOSE messages are processed in the Data Link layer, no additional processing
through the TCP/IP layers is required. Consequently, this type of Ethernet communication is
very fast, providing access time of less than 4ms, since the data is retrieved directly from the
IED communications hardware interface.
These ‘multicast’ broadcasts are unsolicited and do not require any cycling data polling
mechanism. Because the data structures used in GOOSE include direct access to the IED
internal database, and because the internal data model exactly matches the IEC 61850
standard, no data conversions are required.
Sampled Value (SV)

In addition to the GOOSE service the Sampled Value (SV) service transmits a synchronised
stream of current and voltage values. Here the demand is for large amounts of standardised,
high priority, cyclic data throughput.
The SVs are also processed in the Data Link layer and transmitted at a very high rate –
corresponding to the sampling rate of the currents and voltages. Thus, for example, sampling
at 80 messages per cycle, in a 50 Hz system, translates to 4 000 messages/s. Consequently, a
missed sample is rapidly replaced by the next sampled value. Single lost values would be
handled by the receiving application by, for example, interpolating the already received well-
known ones from any A/D conversion.
Manufacturing Message Specification (MMS)

Developed in 1984 for General Motor’s Flexible Manufacturing Initiative (MAP), the
Manufacturing Message Specification (MMS) was originally tied to the OSI communications
stack. Unfortunately it had a reputation for being both complicated and costly due to poor
implementation. However in 1999 it gained a new lease of life when Boeing created a new
version running on Ethernet – using Internet protocols plus RFC (ISO Transport over TCP) in
the transport layer. It has subsequently been standardised as an ISO specification (ISO 9506
parts 1 and 2).
The role of the MMS is illustrated in Figure 7.4.
MMS does not specify

the application interface
Device Device
(e.g. SCADA) MMS specifies the class (e.g. PLC)
of objects that an MMS
server is expected to hold
Request MMS MMS specifies a set of MMS Server

(Command) Client messages that allow
an MMS client to
Remote procedure control an MMS server
call interface Response
(Reply)
Communications Communications
Stack MMS specifies how messages Stack
are encoded for transmission
NETWORK
Switch Router
Figure 7.4. An overview of the role of the MMS.

Object modelling
As distinct from DNP3 in which objects are configured and mapped using purely numerical
terms, IEC 61850 are mapped to a named MMS variable object that results in a unique and
unambiguous reference for each element of data in the model.
As shown in Figure 7.5, any physical device connected to the network, i.e. an IED,
incorporates one or more Logical Devices (LDs) – described by non-standardised names.
In turn, nested within each LD, are one or more Logical Nodes (LN) – a standardised name
grouping of data and associated services related to a specific system function. For example,
all LNs used for automatic controls have names beginning with the letter ‘A’. And all LNs
used for metering and measurement have names beginning with the letter ‘M’. Some further
naming letters and their functions are shown in Table 7.2.
Table 7.2. Example of some standardised naming.
Initial letter Function

of the LN
A Automatic control
C Supervisory control
G Generic functions
I Interfacing/Archiving
L System logical nodes
M Metering and measurement
P Protection
R Protection related
S Sensors
T Instrument transformers
X Switchgear
Y Power Transformers
Z Other Equipment
A
Figure 7.5. Object modelling in which

A PhV
Amps Volts
A PhV
Amps Volts
Pos
Position
Pos
Position B the Logical Nodes (LNs) are nested
within Logical Devices (LDs) that are
MX DC ST CO
Measurements Descriptions Status Controls implemented in servers residing within
Logical Nodes (LNs) IEDs.
MMXU1 XCBR2
Measurement Unit #1 Circuit Breaker #2
Logical Device (LD)

e.g. Relay 1
Physical Device (e.g. IED)
(Network Address)
Network
Each LN has an LN-Instance-ID suffix attached to the LN name. Thus, for example, the
standard name of an LN ‘measurement Unit for 3-phase power’ is MMXU. And a ‘circuit
breaker’ would be XCBR. If there were more than two measurement inputs or circuit
breakers, the LN names would be amended to MMXU1 and MMXU2 or XCBR1 and
XCBR2, respectively.
Each LN may also use an optional application-specific LN-prefix to provide further

identification of its purpose. Thus, referring to Figure 7.5, the syntax used to describe element
‘A’ (current measurement) would be:
Relay1/MMXU1.MX.A
and for element ‘B’ (Breaker Position Control):
Relay1/XCBR2.CO.A
Comparison of DNP3 with IEC61850

Whilst DNP3 has been in the public domain since a 1993, IEC 61850 only became an
international standard in 2004/5. And like any new kid on the block IEC 61850 has its
detractors. Many claim that it’s young, and untested and has yet had time to mellow and
evolve. For example in early editions, there were issues with vendors offering slightly
different solutions – leading to interoperability issues. And although these have been
subsequently resolved, there remain legacy perception issues.
DNP 3 has a huge support base – particularly in the USA where it is in use in over 75% of
North American utilities. And thus DNP 3 still reigns – even if it’s in decline as IEC 61850
starts to dominate in Europe and India.
Whilst DNP 3 focuses on inexpensive endpoints and low-bandwidth communication

channels, IEC 61850 is designed for high-bandwidth communication channels running on
Ethernet with a richer, wider range of features.
In essence, common features of both protocols are: recognition by the NIST (US National
Institute of Standards and Technology) interoperability framework; implementation of
substation automation; and use of XML configuration files.
However, IEC 61850 has more advanced features that include: high-speed peer-to-peer
communication; advanced structured data and naming; and advanced self-description.
In addition IEC 61850 also supports GOOSE – often touted as the major outcome of the IEC
61850 standard – catering, as it does, for huge reductions in inter-device wiring.
Chapter 8. Spanning Tree Protocol (STP)
I n Chapter 4 we saw how Mesh networks provide self-healing’s redundancy with

consequent improvement in the data reliability and security. But such advantages come at
a price!
Consider the configuration shown in Figure 6.1 – with switches 1, 2 and 3 each connecting
several devices – but with only a single connection between the switches. Unfortunately, this
layout exhibits a single point of failure in that should either of the links between the switches
fail, communication between many of the nodes will be lost.
Node 3
Figure 6.1. With only a single

Node 2
Node4 connection between Switches 1, 2 and 3,
this layout exhibits a single point of
Switch 3 failure.
Link 1/3 Link 2/3
Switch 1 Switch 2
Node1
It might seem therefore, that this problem could easily be overcome by creating a redundant
communication link installed between Switches 1 and 2 (Figure 6.2).
Node 3
Node 2
Node4 Figure 6.2. Creation of a redundant link
installed between Switches 1 and 2.
Switch 3
Link 1/3 Link 2/3
Switch 1 Link 1/2 Switch 2
Node1
Unfortunately, such a solution comes at a cost – actually creating several serious problems.
Assume, firstly that Node 3 has been quiescent for more than five minutes (the default time)
and that, as a consequence, its MAC address has been removed from the filter tables of
all the switches.
Next assume that Node 1 wishes to communicate with Node 3 and broadcasts a frame.
Because Node 3’s MAC address is not resident in Switch 1 it must flood all its ports
with the address. The datagram will thus be transmitted through Link 1/3 to Switch 3,
which will again flood all its ports, whereupon it will be delivered to Node 3. At the
same time, the datagram will also be transmitted through Link 1/2 to Switch 2 where the
address will again be flooded to all ports and will be transmitted through Link 2/3 to
Switch 3 – and thence, once again, the same datagram will be delivered to Node 3.
In other words, Node 3 will receive duplicate datagrams.
Another problem also arises as a result of this action. We saw that as a result of the
transmission on Link 1/3 to Switch 3, it flooded its ports in order to transmit to Node 3.
However, in doing so it also sent the datagram back to Switch 2 which in turn also
flooded its ports… The result is that the broadcast is running in the loop in both
directions to cause what is termed a ‘broadcast storm’.
The answer, of course, is to break the loop. The trouble is, however, in breaking the loop we
will lose out on what we were trying to achieve in the first place – redundancy.
So, how can we balance these two requirements?
The solution lies in a prevention mechanism called Spanning Tree Protocol (STP), an
algorithm created by Dr Radia Perlman, whilst working for Digital Equipment Corporation,
that allows the switches to create a loop-free topology over a mesh network.
A key element in STP is the generation, exchange, and processing of data messages called
Bridge* Protocol Data Units (BPDUs) that are used, in conjunction with the STP algorithm,
to allow switches to identify redundant paths and ensure that there is no loop path in the
network. The BDPUs are transmitted using the standardised multicast Layer 2 MAC address
01-80-c2-00-00-00.
*Please note that despite the exclusive use of the term ‘Bridge’, in the context of STP, this term equally
applies to other devices – particularly ‘switches’
Bridge Protocol Data Units (BDPUs)

In reality there are three types of BPDU:
 Configuration BDPUs (CBPDU) used for spanning tree computation;
 Topology Change Notification BDPU (TCN) used to announce changes in the
network topology; and
 Topology Change Notification Acknowledgement (TCA).
Configuration BDPU
Each switch creates its own BPDU which is generated by the bridge management protocol
and carried in the Data field MAC frame. The MAC frame uses a reserved destination group
address, recognized only by switches supporting STP, as defined in IEEE 802.1d, Section 3.
The layout of the frame is shown in Figure 6.3 – with details of the individual fields given
below. The actual role of each field will be explained in further detail at a later stage.
1 2 3 4 5 6 - 13 13 - 17 18 - 25
Protocol
Protocol BPDU Root Path
Version Flags Root Identifier Bridge Identifier
Identifier Type Cost
Identifier
2 bytes 1 byte 1 byte 1 byte 8 bytes 4 bytes 8 bytes
26 - 27 28 - 29 30 - 31 32 - 33 34 - 35
Port Identifier Message Age Max Age Hello Time Forward Delay
2 bytes 2 bytes 2 bytes 2 bytes 2 bytes
Figure 6.3. Construction of the Configuration BPDU frame.
Protocol Identifier: A 2-byte field that identifies the Spanning Tree Protocol (STP) – set to a
value of 0000 0000 0000 0000.
Protocol Version Identifier: A 1-byte field that identifies the current version of the protocol
being used that was specified in the previous field – set to a value of 0000 0000.
BPDU Type: A 1-byte field that identifies the type of BPDU being sent –set to a value of
0000 0000 for a Configuration BPDU.
Flags: A 1-byte field that contains flags used in response to a Topology Change Notification
BPDU.
 Bit 1 is the Topology Change flag. It is used by the root to tell all switches to speed up
their aging timers for their filtering databases.
 Bit 8 is the Topology Change Acknowledgment flag. It is used by a switch receiving a
Topology Change Notification BPDU to acknowledge receipt to the transmitting switch.
Root Identifier: An 8-byte field that contains the bridge identifier of the root for the spanning
tree being deployed.
Root Path Cost: A 4-byte field used to indicate the cost of the path from the transmitting
switch to the root.
Bridge Identifier: An 8-byte field containing the bridge identifier of the transmitting switch.
Port Identifier: A 2-byte field used to identify the port via which this BPDU was transmitted.
Message Age: A 2-byte field used to indicate the age of the current Configuration BPDU.
This parameter allows a receiving switch to discard a BPDU that exceeds Max Age.
Max Age: A 2-byte field used to indicate a timeout value to be used by all switches in the
broadcast domain. The Max Age value is set by the root.
Hello Time: A 2-byte field defining the time interval between generation of Configuration
BPDUs by the root. It is used to facilitate the monitoring of protocol performance by
management functions.
Forward Delay: A 2-byte field that defines the time a switch port must wait in the listening
state, and then again in the learning state, before entering the forwarding state.
Topology Change Notification BDPU

The layout of the frame is shown in Figure 6.4 – with details of the individual fields given
below. Again, The actual role of each field will be explained in further detail at a later stage.
1 2 3 4
Protocol Figure 6.4 . Construction of the Topology Change

Protocol BPDU
Version
Identifier Type Notification BPDU frame.
Identifier
2 bytes 1 byte 1 byte
Protocol Identifier: A 2-byte field that identifies the Spanning Tree Protocol (STP) – set to a
value of 0000 0000 0000 0000.
Protocol Version Identifier: A 1-byte field that identifies the current version of the protocol
being used that was specified in the previous field – set to a value of 0000 0000.
BPDU Type: A 1-byte field that identifies the type of BPDU being sent – this time set to a
value of 1000 0000 to indicate that this is a Topology Change Notification BPDU.
Preventing loops
The creation of a loop-free topology is created in a number of distinct phases. Firstly, all the
switches in an STP-enabled network need to have a common view of the complete network
topology. In order to realise this common view it is first necessary to determine an initial
point of reference through the election of what is termed a ‘root bridge’ – using a process
called ‘Root Bridge Election’.
Figure 6.5 shows a network comprising a number of switches, routed through links – with the
numbers representing the switch IDs.
Switch 44
Figure 6.5. Network comprising a
Link A Link B number of switches routed through
links.
Switch 23 Link C Switch 32
Link D Link G
Link E Link H
Switch 30 Switch 50
Link F Link J Link K
Switch 96
Link L
Switch 67
Root Bridge election

Although bridges do not normally require MAC addresses to operate, STP-enabled devices
are provided with a vendor-assigned 48-bit MAC address in order to identify them. Each
bridge/switch is also assigned a 16-bit user-configurable ‘Bridge Priority’ field – the two
together making up a unique ‘Bridge ID’.
In Spanning Tree technology the root bridge

44/1 44/2
is the bridge having the lowest ‘Bridge ID’
Switch 44 (Figure 6.6).
Link B
Link A
Figure 6.6. The Root Bridge is the bridge

23/1 35/2 having the lowest ‘Bridge ID’.
23/2 Link C 35/1

Switch 23 Switch 35
Root
Bridge
In order to compare two ‘Bridge IDs’, firstly the Bridge Priorities are compared and any
bridge whose number is less than the default value of 0x800 (32768) will be targeted as a
potential root. If two bridges have equal priorities then, and only then, are the MAC addresses
compared – again with the bridge whose MAC address number is the lowest being selected as
the root.
Root port election

Following the election of the Root Bridge, the next task is for every non-root switch to
determine where it is in the network in relation to the Root Bridge.
This action is implemented by assigning each port as either a Designated Port, forwarding
traffic away from the Root Bridge, or a Root Port. Only one Root Port can be assigned on
each non-root switch and will always points toward the current Root Bridge.
Election of the Root Ports is undertaken by determining the ‘cost’ of each link. In this sense
the term ‘cost’ is not a monetary value but a value based on the transmission speed of the link
assigned to the associated port – a high-speed link warranting a low-cost and a low speed
warranting a high cost. The original IEEE 802.1d standard defined Path Cost as 1000 Mbps
divided by the link bandwidth in Mbps. The IEEE now uses a nonlinear scale for Path Costs,
as shown in Table 6.1. These would be set by the network administrator.
Table 6.1. Port Cost values for different link speeds.

Link speed Port cost value
10 Gbps 2
1 Gbps 4
100 Mbps 19
16 Mbps 62
10 Mbps 100
A Path Cost is calculated as the accumulated port costs from a switch to the Root Switch. All
the ports of the Root Switch itself are set to 0. When a switch receives a BDPU in its port it
increments the path cost with the cost of the incoming port. In this manner the port with the
lowest resulting Root Path Cost, on every non-root switch, is elected as the Root Port.
As an example, assume that the links have bandwidths and associated costs as per Table 6.2
and as illustrated in Figure 6.7.
Table 6.2. Port Cost values for different link speeds.

Link Link speed Port cost value
Link A 100 Mbps 19
Link B 1 Gbps 4
Link C 10 Mbps 100
44/1 44/2
Switch 44 Figure 6.7. Associated costs derived
from Table 6.2.
4
19
23/1 35/2
23/2 100 35/1

Switch 23 Switch 35
Root
Bridge
Referring to Figure 6.8, the Root Path Cost value is determined in the following manner:
RPC = 0 + 19 = 19 RPC = 100 + 4 = 104

44/1 44/2 Figure 6.8.Determining the
Switch 44 Root Path Cost value.
4
19
23/1 RPC = 0 35/2 RPC = 19 + 4 =23
RPC = 0 RPC = 0 + 100 = 100

23/2 100 35/1
Switch 23 Switch 35
Root RPC = Root Path Cost

Bridge
1. The Root Bridge (Switch 23) sends out a BPDU with a Root Path Cost value of 0.
2. When the next-closest switches (Switches 35 and 44) receive the BPDU, they add the
Path Costs of their own ports on which the BPDU arrived.
3. In turn, the adjacent switches send out BPDUs with this new cumulative value as the Root
Path Cost.
4. In this manner the Root Path Cost is incremented by the ingress port Path Cost as the
BPDU is received at each switch down the line. Note that the emphasis is on
incrementing the Root Path Cost as BPDUs are received – not as they go out.
5. The port with the lowest resulting Root Path Cost on every non-root switch is finally
elected as the Root Port (Figure 6.9).
Root port
RPC = 0 + 19 = 19 RPC = 100 + 4 = 104
44/1 44/2 Figure 6.9. The port with the
Switch 44 lowest resulting Root Path
Cost on every non-root
4 switch is finally elected as
19
the Root Port.
Root port
23/1 RPC = 0 35/2 RPC = 19 + 4 =23
RPC = 0 RPC = 0 + 100 = 100

23/2 100 35/1
Switch 23 Switch 35

Bridge
After incrementing the Root Path Cost, the switches record the value in their memories.
When a BPDU is received on another port and the new Root Path Cost is lower than the
previously recorded value, this becomes the new Root Path Cost. In addition, the lower cost
tells the switch that the path to the Root Bridge must be better using this port than it was on
other ports.
Designated Port Election

In order to remove the possibility of bridging loops, only one of the links on a segment
should forward traffic to and from that segment. This is referred to as the Designated
Port.
The election of one Designated Port on each network segment (Figure 6.10) is the final
step of the STP’s computational process. The election of the Designated Port is also
based on the Root Path Cost. In case the two or more ports have the same Root Path
Cost, the switch with the lower Sender Bridge ID wins and its corresponding port is
selected as the segment’s Designated Port. Keep in mind that the Root Bridge is the only
bridge in the network that does not have a root port since they are considered Designated
Ports and cannot be blocked.
Root port
RPC = 0 + 19 = 19 RPC = 100 + 4 = 104
44/1 44/2
Switch 44
Designated port
4
19
Designated port Root port Figure 6.10. Election of one

23/1 RPC = 0 35/2 RPC = 19 + 4 =23 Designated Port for each
RPC = 0 RPC = 0 + 100 = 100
network segment.
23/2 100 35/1
Switch 23 Switch 35
Designated port
Bridge
Any port which is not a Root Port or a Designated Port moves into the Blocking State
(Figure 6.11) where it cannot receive or transmit frames, ensuring that the network is
loop-free.
Root port
RPC = 0 + 19 = 19 RPC = 100 + 4 = 104
44/1 44/2 Figure 6.11. Any port
Switch 44
Designated port which is not a Root Port
or a Designated Port
19
4 moves into the Blocking
State.
Designated port Root port
23/1 RPC = 0 Blocked port 35/2 RPC = 19 + 4 =23
RPC = 0 RPC = 0 + 100 = 100

23/2 100 35/1
Switch 23 Switch 35
Designated port
Bridge
STP states
As we’ve seen, each port of a switch must progress through several states in order to
participate in STP. A port begins its life in a Disabled state – moving through several
passive states and, if allowed to forward traffic, finally into an active state.
Disabled
This state, in which the port is completely non-functional (unable to receive or transmit
any type of frame), is not actually part of the normal STP port progression. The
Disabled state is normally set by the network administrator or by the system in the event
of a fault condition.
Blocking
In the Blocking State a port cannot receive or transmit data so that no bridging loops
can be formed. Although it cannot learn MAC addresses, it can receive BPDUs.
Consequently, in the event that other links might fail, the STP algorithm can determine
if the port may transition to the forwarding state.
Listening
In the Listening state the port is moving out of the Blocking state and being prepared
for activity. It still does not learn or forward addresses but can now send as well as
receive BDPUs so that it can actively participate in the STP process.
Learning
The port is allowed to move from the Listening state into the Learning state after a
period of time determined by the Forward Delay field (typically 15 s) in the
Configuration BDPU. In addition to receiving and sending BDPUs the port can now
populate the MAC address table. However it cannot forward data frames.
Forwarding
After a period of time spent in the Learning state, the port moves into the Forwarding
state where it functions as any other switch port – filtering and forwarding frames.
STP timing
Having now had an overview of the STP in action, it might be useful to revisit the last
three fields of the Configuration BPDU – the Max Age; the Hello Time; and the
Forward Delay.
Max Age
This two-byte field holds the time interval that the switch stores a BDPU before
discarding it – a default value of 20 s. Each switch port stores a copy of the ‘best’
BDPU received. If a port loses contact with the BDPU’s source, then following a
timeout of the Max Age, the switch assumes a topology change to have occurred.
Hello Time
This two-byte field determines the time interval between successive transmissions of the
Configuration BDPUs from the root bridge – a default value of 2 s.
Forward Delay: This 2-byte field defines the time that a switch port must wait in the listening
state, and then again in the learning state, before entering the forwarding state. The default
value is 15 s.
Convergence
The change in a network’s topology can occur due to a variety of reasons: a lost link; a
lost bridge; the addition of a link or bridge; or by network changes made by the system
administrator. When such a change occurs, the STP must determine whether there are
redundant paths that must be blocked to prevent data loops, or activated to maintain
communications between the various network segments. This process is referred to as
convergence.
In order to announce such a change, STP generates a Topology Change Notification

(TCN) BDPU.
As stated previously (Figure 6.4) the TCN BDPU contains only three fields – with the
last one, the BPDU Type, indicating that it is a Topology Change Notification BPDU. In
other words the TCN BPDU carries no data about the change but only informs recipients that
a change has occurred.
Thus, when a non-root switch changes the active topology, it transmits a TCN BDPU on its
root port – continuing to transmit every Hello Time interval until it receives an
acknowledgment from its nearest upstream device. In this manner the TCN BPDU is
propagated on towards the Root Bridge – with each switch sending its own
acknowledgments.
When the Root Bridge receives the TCN BPDU, it also sends out an acknowledgment – with
the Topology Change flag set. This is relayed to every other bridge in the network to signal
the topology change and force all the other bridges to shorten their bridge table aging times
from the default of 300 s to only the Forward Delay value of 15 seconds.
This, in turn, flushes out learned MAC address locations much quicker than normal – easing
the bridge table corruption that might occur as a result of the change in topology. This
condition lasts for the sum of the Forward Delay and the Max Age times (15 + 20 = 35 s).
In order to clarify this procedure, let’s have a look at the network we used previously where
the link between the Root Bridge (Switch 23) and Switch 44 has failed (Figure 6.12).
Figure 6.12.The link between the Root Bridge (Switch 23) and Switch 44 has failed.
1. Switch 44 detects that the link has gone down on its Port 44/1 and at the same time the
Root Bridge (Switch 23) detects the link down on its Port 1/2.
2. Because Port 44/1 is down, and the BPDU is no longer valid, Switch 44 removes the
previous ‘best’ BPDU it had received from the Root Bridge over Port 44/1.
3. Currently, Switch 44 remains unaware that another (potential) path exists to the Root
Bridge.
4. At the same time the Root Bridge is aware of the link down condition on its own Port
23/1 and thus transmits a Configuration BPDU, with the TCN bit set, from its port 23/1 –
informing Switch 44 of the topology change.
5. Remember that although the Port 35/1 is blocked it is still capable of receiving BDPUs.
Consequently both Switches 44 and 35 receive the TCN message and react by shortening
their bridging table aging times to the Forward Delay time.
6. At this point, neither Switches 44 nor 35 know how the topology has changed – only that
they were forced to age out their recent bridging table entries.
7. Meanwhile, Switch 35 and waits for the Root Bridge to transmit another Configuration
BPDU TCN message – which it again receives on Port 35/1 which was previously in the
Blocking state.
8. This BPDU now becomes the ‘best’ one received from the Root Bridge so that Port 35/1
becomes the new Root Port.
9. Switch 35 can now progress Port 35/1 from Blocking through the Listening, Learning,
and Forwarding states.
As a result of the link failure, the topology has been changed and STP has converged again.
The total time that users on Switch 35 lost connectivity was roughly the time that Port 35/1
spent in the Listening and Learning states. With the default STP timers this amounts to about
two times the Forward Delay period of 15 s – or 30 s total.
Chapter 9. Rapid Spanning Tree
Protocol (RSTP)
I n practice, STP can actually take anything from 30 to 50 s to re-converge following

a topology change. In order to provide a faster recovery the IEEE introduced Rapid
Spanning Tree Protocol (RSTP) (IEEE 802.1w) – having backwards compatibility
with STP.
Probably the most important feature introduced by 802.1w is rapid transition. RSTP
provides significantly faster spanning tree convergence – responding to a topology
change within 3xHello times (3 x 2 s (default|)) or within a few milliseconds of a
physical link failure.
Whilst the legacy STP waited passively for the network to converge before it turned a port
into the forwarding state, RSTP is able to actively confirm that a port can safely transition to
the forwarding state without having to rely on any timer configuration.
As opposed to STP, RSTP clearly distinguishes between the state of a port and the role of a
port.
RSTP Port States

Whilst, as previously described, STP defines five port states, RSTP defines only three:
Forwarding; Learning; and a new state, Discarding.
Discarding describes a port where all the received frames are discarded and no learning takes
place. There are thus no entries in the filtering database and no entries in the filtering
database that point to this port and no traffic being forwarded across it.
RSTP Port Roles

Whereas STP defines the port roles of Designated and Root, RSTP adds three new port roles:
Disabled (formally defined as a port state in STP); Backup port; and Alternate port. In STP
these latter two new roles would have been called Blocked.
A Backup port is paralleled to a Designated port such that if a switch has a Designated port to
a particular collision domain, and has a second port connecting to that same collision domain,
the port is declared a Backup port. This is detected by the switch as it senses its own
Configuration BPDU arriving on that port.
An Alternate port is essentially a backup to the Root Port. If the Root Port is lost the
Alternate Port is quickly used as the new Root Port
In order to illustrate the concept of Port Roles, let’s have a look at Figure 7.1. Since Switch
14 is the Root Bridge switch in this network, both of its ports are Designated ports. Switches
82, 65, and 47 have all selected their ports 82/1, 65/1 and 47/1 respectively, as the Root Ports
because they are the ports with the lowest Root Path Cost is on each switch.
Root
Bridge
Designated Designated
port port
14/1 14/2
Switch 14
38
19
Root port Root port

82/1 47/1
Designated Designated
port port
82/2 19 65/1 65/2 19 47/2

Switch 82 Switch 65 Switch 47
Root port
Alternate
Root port 65/3 65/4 port
Backup
19 38 port
Figure 7.1. Illustration of RST port roles.
Since only one of the links on a segment should forward traffic to and from that
segment the port connecting this bridge to the network segment is referred to as the
Designated Port. On this basis, ports 82/2 and 47/2 on switches 82 and 47, respectively,
are declared Designated Ports. This means that, assuming the ports have cleared the learning
state, all ports on Switches 14, 82, and 47 are in the Forwarding state.
Switch 65 has selected Port 3 as the Designated Port for that collision domain because it has
detected that there is no other switch in that domain. It has, however, determined that Ports 3
and 4 are both connected to the same domain, and has declared Port 4, which has a high root
port cost, as a Backup Port. Since Port 2 is neither a Root Port (Port 1 has a lower root path
cost); a Designated Port (Switch 47 has a lower Root Path Cost and is connected to that
collision domain); nor a Backup Port (since it is not connected to the same collision domain
as any other Switch 65 port); it is declared an Alternate Port. This means that Ports 4 and 2
are both in the Discarding state.
In STP, the Configuration BPDUs are initiated by the root and are passed down through the
spanning tree. If there is a failure, the Configuration BPDUs cannot get past this point – thus
indicating to all of the devices below that point that something is wrong. Unfortunately,
whilst they know ‘something’ is wrong they do not know ‘what’ is wrong or ‘where’ the
problem lies.
In RSTP, each switch is responsible for initiating its own Configuration BPDUs locally –
based on a timer. Thus, if a switch stops seeing Configuration BPDUs on its root port, it
knows the failure is with the designated switch for that collision domain.
A second feature of RSTP is that if a switch receives inferior information about the Root
Bridge or Root Path Cost on a designated port then, instead of discarding it (as in STP) it
stores that information (rather than discarding it), and sends its own Configuration BPDU.
This means that, in the event the switch loses its Root Port, it has up-to-date information on
all of its ports and can immediately select a new Root Port.
In order to achieve fast convergence on a port, RSTP relies upon two new variables: Edge
Ports and Link Ports.
Edge Ports
An Edge Port is a Designated Port that is operating in a half-duplex mode and connects to a
collision domain where there are no other switches present. That would include any port that
directly attaches to an end-station, a router, a server, or a hub (Figure 7.2). These ports are
automatically made part of the spanning tree and transition directly to the forwarding state
– skipping the listening and learning stages, regardless of what happens on the other ports.
A switch can automatically detect an Edge Port by noting the absence of Configuration
BPDUs from any attached system. Alternatively it can be manually configured by the
network administrator.
14/1 14/2
Switch 14
Figure 7.2. Example of Edge Port operating in
14/3 Edge Port a half-duplex mode and connecting to a hub –
a collision domain where there are no other
Half duplex
switches present.
H Repeater (Hub)
Node 1 Node 4
Node 2 Node 3
Link Ports
Ports that are not edge ports are referred to as Link Ports and participate in the spanning
tree process.
In switched networks most links operate in full-duplex mode and are thus treated as
point-to-point links by RSTP. RSTP can only achieve rapid transition to the forwarding
state on edge ports and on point-to-point links. The Link Port is automatically derived
from the duplex mode of a port. A port that operates in full-duplex is assumed to be
point-to-point, while a half-duplex port is considered as a shared port by default.
Fast Recovery
Fast network recovery on RSTP encompasses a wide range of mechanisms.
If a Designated Port fails on a switch having a Backup Port, it engages immediately

without fear of forming a loop since the switch still has the lowest Root Path Cost for
that collision domain – regardless of the number of switches attached to it.
If either a Root Port or a Designated Port fails, and it is in half duplex mode (e.g.
attached to a hub), then the original STP is engaged.
For point-to-point Link Ports, if failure occurs on a Designated Port, the responsibility
for recovery lies with the switches in the tree below the failure – with the switch
actually experiencing the failure no longer providing the designated port for that
collision domain.
What happens when a switch experiences a Root Port failure? In the event of a Root
Port failure (e.g., the port physically goes offline or it stops seeing Configuration
BPDUs from the up-tree switch), it immediately places all the Designated Ports into the
Discarding State to prevent loops from forming. It then selects its next best port to be
the new Root Port – moving it into the learning state on its way to Forwarding. It then
sends a Configuration BPDU proposal on all of its other link ports.
This configuration BPDU notifies the surrounding switches and gives them an
opportunity to reconfigure. However, switches receiving the Configuration BDPU on a
Backup, Alternate, or Designated Port, will not change their configuration since, if they
were not using the switch that detected the loss to get to the Root Bridge previously,
they will certainly not use it when it changes to a worse path.
The only switches of concern are those receiving it on their Root Port – who
immediately place their Designated Ports into Discarding State; select a new Root Port;,
and then respond to the original switch with a configuration BPDU response.
The original switch can thus reconfigure and determine which roles to assign to which
ports, on a port-by-port, with no fear of forming loops.
This essentially creates a cascading effect, away from the Root Bridge, down through
the spanning tree, which is redeployed with no need for any switch to wait in a
Listening State. In effect, no switch activates a port until it is certain that port cannot
participate in a loop. This is one of the major elements that allows RSTP to achieve
faster convergence times than STP.
RSTP maintains backup details regarding the Discarding Status of ports – thus avoiding
timeouts if the current Forwarding Ports were to fail or BPDUs were not received on the
Root Port within a certain interval.
Summary
In summary, RSTP provides significantly faster spanning tree convergence than STP.
As distinct from STP, RSTP assumes that the three STP Port states (Listening, Blocking
and Disabled) are all the same and do not forward frames or learn MAC addresses.
Hence, RSTP places them all into a new state called Discarding State. Learning and
Forwarding ports remain more or less the same.
Furthermore, unlike STP, where bridges only send out a BDPU when they see one on
their Root Port, RSTP-enabled switches send out BPDUs every Hello time, containing
current information.
And finally, whilst STP defines only to Port types (Root Port and Designated Port),
RSTP includes two additional Port types – Alternate Ports and Backup Ports. An
Alternate Port has an alternative path or parts to the root but is currently in a Discarding
State (may be considered as an additional unused Root Port). A Backup Port can be
considered as an additional unused Designated Port.
Chapter 10. Multiple Spanning Tree
Protocol (MSTP)
D espite the convergence speed advantages offered by RSTP over STP it still
suffers from several drawbacks.
The first lies in the fact that both RSTP and STP are still based on the deployment of a
single spanning tree which, in a large switched network, causes a relatively long
convergence time.
Secondly, by adopting only a single spanning tree, all the VLANs in the network share
the same one. Unfortunately, this can lead to problems in ensuring that data
communications in each VLAN are carried out along the spanning tree.
Finally, because Blocked links do not forward traffic and do not, therefore, participate
in load balancing, this can lead to inefficient use of bandwidth.
These obstacles are overcome in a system called Multiple Spanning Tree Protocol
(MSTP) which is defined in IEEE 802.1s.
Like RSTP, MSTP allows for rapid port state transition and is backwards compatible with
both STP and RSTP.
MSTP features
MSTP enjoys several advantages over both STP and RSTP.
Firstly, MSTP divides a switched network into multiple Regions – each containing multiple
spanning trees independent of one another. MSTP uses the Common and Internal Spanning
Tree (CIST) to exchange information between Regions and thus prevent loops from forming
in the network.
In essence, an MSTP Region is simply a collection of switches, sharing the same view of a
physical topology, that a petition into a set of logical topologies.
In MSTP, load balancing is implemented by what are termed Instances that are independent
spanning trees each – corresponding to a group of VLANs. By mapping multiple VLANs to
an Instances, both transmission overheads and network resources can be reduced.
With RSTP implemented on a large network, any given switch could run up to 4094
Instances of spanning tree – each with its own BPDU conversations, root bridge election, and
path selections. With MSTP, one path could run several VLANs and another path could run
the rest – such that there are only two Instances of spanning tree.
Chapter 10. Multiple Spanning Tree Protocol (RSTP) 92
Referring to Figure 8 .1, in legacy spanning tree implementations there would be only one
Instances of spanning tree for all the VLANs – with Switch 14 the Root Bridge for all of
them. As a result, there would be just one Instances of spanning tree and all user traffic is
therefore pass through switch 14. This is an inefficient waste of critical bandwidth.
Root
Bridge
Switch 14
Port Blocking for

even VLANs
Switch 44
Port Blocking for Switch 54
odd VLANs
Figure 8 .1. In legacy spanning tree implementations there would be only one Instances of
spanning tree for all the VLANs with Switch 14 the Root Bridge for all of them.
VLANs can be assigned arbitrarily to any Instances. For the design shown in Figure 8.1,
MSTP only creates two Instances of spanning tree with Switch 14 handling even VLANs and
Switch 44 handing odd VLANs. MSTP provides load-balancing capability for groups of
VLANs rather than each VLAN – grouping them to reduce the number of Instances in the
network.
Terminology changes
The first thing to note is that MSTP introduces several new terms, several new
acronyms, and several new concepts. Firstly, let’s have a look at some of the changes
in regard to the terminology used in MSTP as distinct to STP and RSTP.
ST – Spanning Tree
STP – Spanning Tree Protocol
RST – Rapid Spanning Tree
RSTP – Rapid Spanning Tree Protocol
MST – Multiple Spanning Tree
MSTP – Multiple Spanning Tree Protocol
CST – Common Spanning Tree
IST – Internal Spanning Tree
CIST – Common and Internal Spanning Tree
MSTI – Multiple Spanning Tree Instance
BPDU – Bridge Protocol Data Unit
At first glance Common and Internal Spanning Tree (CIST) and Common Spanning
Tree (CST) might appear very similar. However, whilst CIST is defined “as a single
topology connecting all Bridges (STP, RSTP, MSTP) via one active topology”, CST is
defined as “the topology connecting all STP/RSTP Bridges and MSTP Regions”. In the
context of CIST, MST Regions are treated as a single RSTP Bridge.
In a nutshell, CIST differs from CST in that it includes the logical connectivity through
MST Bridges and Regions.
The ‘Multiple Spanning Tree Instance (MSTI)’ may be defined as one of a number of
Spanning Trees calculated by MSTP within an MST Region. 64 distinct MSTIs (MST
topologies) are calculated and maintained by MSTP. However, not all the topologies are
actively used to carry traffic since not all the VLANs may be in use.
One important change in regard to the Bridge Protocol Data Unit is that the term
‘Configuration’ falls away and is replaced by the acronym ‘ST BPDU’. The term
‘Topology Change Notification BDPU’ remains but is generally referred to by the acronym
TCN BPDU. Other acronyms include: RST BPDU and MST BPDU.
Apart from the name change, several fields have been added to the BDPU frame. These
include ‘Version 1 Length’, ‘Version 3 Length’, and the ‘MSTP Extension’ field
(Figure 8.2).
1 2 3 4 5 6 - 13 14 - 17 18 - 25
Protocol CIST CIST External

Protocol BPDU CIST Regional
Version Flags CIST Root Identifier Root Path
Identifier Type Bridge Identifier
Identifier Cost
2 bytes 1 byte 1 byte 1 byte 8 bytes 4 bytes 8 bytes
26 - 27 28 - 29 30 - 31 32 - 33 34 - 35
CIST Port
Message Age Max Age Hello Time Forward Delay
Identifier
2 bytes 2 bytes 2 bytes 2 bytes 2 bytes
36 37 - 38 39 - 102
Version
1 Length Version
MSTP Extension
=0 3 Length
1 byte 2 bytes 64 bytes
39 - 89 90 - 93 94 - 101 102
MST CIST
CIST Internal CIST Bridge Remaining
Configuration Root Path Cost Identifier
Identifier Hops
51 bytes 4 bytes 8 bytes 1 byte
Figure 8.2. The ‘ST BDPU’ (formerly Configuration BDPU) includes several
additional fields – ‘Version 1 Length’, ‘Version 3 Length’, and the ‘MSTP Extension’
field.
MSTP Regions
MSTP differs from other spanning tree implementations in that it combines several VLANs
into a logical spanning tree Instances. Consequently, the BPDU must be tagged so that the
receiving devices can identify the Instances and the VLANs to which each device applies.
This introduces the concept of MST Regions where, in effect, a group of switches is placed
under a common administration.
Each switch running MSTP must the same three single MST configuration attributes:
1. An alphanumeric configuration Region name (32 bytes).
2. A configuration Revision Number (2 bytes).
3. A 4096-element table that associates each of the potential 4096 VLANs, supported on
the chassis, to a given Instances.
In order to ensure consistent mapping of the VLANs to Instances, the protocol must be able
to exactly identify the boundaries of the Regions. Consequently, the characteristics of the
Region are included in the BPDUs.
Once a switch receives a BPDU, the switch extracts a digest of the VLANs-to-Instances
mapping table and compares it with its own computed digest. If the digests differ, the port on
which the BPDU was received is at the boundary of a Region.
In generic terms, a port is at the boundary of a Region if the designated bridge on its segment
is in a different Region. In Figure 8.3 the port on Switch 3 is at the boundary of Region B,
whereas the ports on Switches 1 and 2 are internal to Region A.
CST
Switch 2 Switch 1 Switch 3
Region A Region B
Figure 8.3. Illustrating the concept of boundaries in which the port on Switch 3 is at the
boundary of Region B, whereas the ports on Switches 1 and 2 are internal to Region A.
Figure 8.4 shows two functionally equivalent networks. In a typically bridged network, a
blocked port would be found between Switches 2 and 3 and, instead of blocking on Switch 7,
the second loop would be broken by a blocked port somewhere in the middle of the MST
Region.
However, due to the IST, the entire Region appears as one of virtual bridge that runs a single
spanning tree (CST) – and thus the virtual bridge blocks an alternate port on Switch 2 and a
virtual bridge is on the Switch 6/7 segment – leading Switch 7 to block its port.
CST CST
Root 1 Switch 8 Root 1 Switch 8
Switch 2 Switch 2
Switch 3
IST Switch 4
Switch 5 Switch 6 Switch 7 MST Region

Switch 5 Switch 7
Figure 8.4. Functionally equivalent networks.
Internal Spanning Tree (IST)

According to the IEEE 802.1s specification, MSTP requires at least two spanning tree
topologies (two Instances):
 One Internal Spanning Tree (IST) (Instance 0)

 One or more Multiple Spanning Tree Instances (MSTIs) (user-defined)
A total of 15 MST Instances +1 IST can be configured under one Region.
The IST Instances extend the CST inside the MST Region – sending and receiving BPDUs to
the CST. In effect, the IST can represent the entire MST Region as a CST virtual bridge to
the outside world.
By default, all VLANs are mapped to the IST. Other MSTP Instances can be enabled and are
referred to as Multiple Spanning Tree Instances (MSTIs).
Separate from the IST, each MSTI assigns its own priorities to the switches and uses its own
link-costs to develop its own logical topology. Since MSTP does not send MSTI information
in separate BPDUs, this information is piggybacked into the IST BPDU using a special M-
Record field (one for each active MSTI) that, amongst others, carries root priority, designated
bridge priority, port priority and root path cost.
CIST Root Bridges Election Process

The election process for CIST root bridges is quite complex and is briefly outlined below:
1. When a switch boots up, it declares itself as a CIST Root and CIST Regional Root –
announcing this through its outgoing BPDUs.
2. The switch will continue to broadcast its best known CIST Root and CIST Regional Root
on all internal ports – adjusting the BPDU content on receipt of updated information.
3. On the boundary ports, the switch advertises only the CIST Root Bridge ID and CIST
External Root Path Cost – thus hiding the details of the region’s internal topology.
4. The CIST External Root Path Cost is the cost to reach the CIST Root across the links
connecting the boundary ports – i.e. the inter-region links. When a BPDU is received on
an internal port, this cost is not changed. When a BPDU is received on a boundary port,
this cost is adjusted based on the receiving boundary port cost. Consequently, the CIST
External Root Path Cost is propagated unmodified inside any Region.
5. Only a boundary switch, the switch with the lowest cost to reach the CIST Root, can be
elected as the CIST Regional Root. If a boundary switch learns of a better CIST External
Root Path cost, received on its internal link, it will relinquish its role of CIST Regional
Root and start broadcasting the new metric from its boundary ports.
6. Every boundary switch needs to block its boundary ports properly. If the switch is a CIST
Regional Root, it elects one of the boundary ports as the ‘CIST Root port’ and blocks all
other boundary ports. If not, it will mark the boundary ports as CIST Designated or
Alternate.
7. Following construction of the CIST, every Region will have one switch possessing a
single port unblocked in the direction of the CIST Root – this is the CIST Regional Root.
All boundary switches will broadcast the Region’s CIST Regional Root Bridge ID from
their non-blocking boundary ports. From an outside perspective, the whole Region will
appear as a single virtual bridge with the Bridge ID = CIST Regional Root ID and single
root port elected on the CIST Regional Root switch.
8. The region that contains the CIST Root will have all boundary ports unblocked and
marked as CIST designated ports. Effectively the region would look like a virtual root
bridge with the Bridge ID equal to CIST Root and all ports being designated.
Chapter 11. Building Automation and
Control network (BACnet)
A
typical building application might comprise an HVAC system, a lighting system,
and an integrated security/fire alarm system. Traditionally, each would comprise a
separate entity with its own wiring and sensors. Integration of these separate entities
into a single integrated system can offer huge savings in physical resources – not just in
wiring but in shared sensors and outputs. Such duplicated shared resources can also result in
increased efficiencies in eliminating inputs and outputs.
In this regard, BACnet (Building Automation and Control network) is a non-proprietary,

open protocol communications standard providing interoperability between different
cooperating building automation systems and devices – including HVAC, lighting, life safety,
access control, transportation and maintenance.
BACnet is a written specification that includes the type of cable to be used through to
instructions on how to initiate a particular information request or command. Its rules are
specifically designed for building automation and control equipment, covering such tasks as
how to request a temperature reading, send a status alarm or establish a fan schedule.
Originally developed under the auspices of the American Heating Refrigerating and Air-
Conditioning Engineers (ASHRAE) BACnet has become both an ISO and ANSI standard.
A key feature of BACnet is its wide range of interoperability – ranging from simple
information exchange through to complex interoperation between competing components
devices and systems.
The BACnet protocol offers a flexible range of networking options including: Ethernet,
point-to-point over RS-232, Master-Slave and Token-Passing over RS-485, and LonTalk.
BACnet’s message format is specifically designed to facilitate communication related to

building automation and control and is applicable to a wide range of building automation
needs including: HVAC control, fire detection and alarm, lighting control, security, ‘Smart’
lifts (elevators), and the ability to interface with the power utility.
Objects
In order to accomplish this BACnet specifies a common language (a standard set of
communication rules) so that each device on the network has a similar look and feel. This is
achieved through the use of an object-oriented model to represent the information. This
allows physical inputs and common functions such as analog and binary input, output, and
metrics; control loops; and schedules to be organised in a common fashion.
This interoperability is accomplished by modelling each device in terms of one or more

information objects. Objects may represent a single physical point, or a logical grouping of
points, that performs a specific function. Regardless of the device in which they reside, all
objects provide a common network view.
The properties of an object may be thought of as a two-column table, as illustrated in Table

9.1, in which a temperature sensor is represented as a BACnet Analog Input object with a few
of the properties that might be available.
Table 9.1. Defining an object.

Object_ Identifier AI-1
Object_Name Space Temperature
Object_Type Analog Input
Units Celsius
Device_Type Pt 100 RTD
Description Conference Room A
Present_Value 22.4
Status_Flags Normal, InService
High_Limit 26.0
Low_Limit 20.0
On the left is the property and on the right the property’s value. Whilst some properties are
read-only (the properties can only be read but not changed) others can be changed (written).
Currently, BACnet specifies 123 properties of objects – three of which, the Object_Identifier,
the Object_Name, and the Object_Type, must be present in every object.
In this example the Object_ Identifier (AI-1) is the equivalent of a tag number; the
Object_Type is identified as an Analog Input; and the Object_Name tells us what we are
measuring,
BACnet objects also have two Classes of properties – ‘required’ properties that must exist in
the device and ‘optional’ properties that exist at the discretion of the device manufacturer. In
the example given above, the Present_Value of the AI object is a required object, whilst the
Description property is an optional property that the device manufacturer may, or may not,
this support.
Originally centred on 25 standard objects, covering many common and generally used
applications, the number has gradually been increased and there are currently 50 standard
objects (Table 9.1) covering a wide range of generic functionality. However, vendors are
also able to implement their own additional object types allowing them to extend BACnet’s
functionality without the need to change the standard. These vendor-specific may include
whatever properties the vendor chooses since, irrespective of whether it is proprietary or non-
standard, it’s read or written in the same manner. This feature enables vendors to extend
BACnet– adding functionality as and when required – without ever changing the standard
itself.
Table 9.1. There are currently 50 standard objects residing in the BACnet library.
Access Credential Access Door Access Point Access Rights Access User
Access Zone Accumulator Analog Input Analog Output Analog Value
Averaging Binary Input Binary Output Binary Value Bit String Value
Calendar Character String Value Command Credential Data Input Date Pattern Value
Date Value Date Time Pattern Value Date Time Value Device Event Enrolment
Event Log File Global Group Group Integer Value
Large Analog Value Life Safety Point Life Safety Zone Load Control Loop
Multi-state Input Multi-state Output Multi-state Value Network Security Notification Class
Octet String Value Positive Integer Value Program Pulse Converter Schedule
Structured-View Time Pattern Value Time Value Trend Log Trend Log Multiple
Whilst objects represent the actual information, these are grouped into what is termed a
‘BACnet Device’ – a collection of objects that represent the functions that are actually
present in a real device (Figure 9.1).
DEVICE
Figure 9.1. Representation of a BACnet device.
SCHEDULE BI
LOOP BO
GROUP AI
AV AO
Services
Since BACnet is based on a ‘Client-Server’ communication model, the message mechanisms,
used to access a property or request an action from a BACnet Object, are called ‘services’
and are carried out by the server on behalf of the client.
The Services level is thus concerned with making requests and interoperating. Services
determine how one BACnet device gets information from another device, commands a device
to perform certain actions (through its objects and properties), or communicates events to
other objects.
Included among the 32 standard services, related to accessing the properties of the objects,
are:
 Read-Property
 Read-Property-Conditional
 Read-Property-Multiple
 Write-Property
 Create-Object
 Delete-Object
 Add-List-Element
 Remove-List-Element
These names are essentially self-descriptive. Thus, for example a device incorporating a
temperature sensor might perform the service of Reading the temperature (Read-Property)
and Writing this information to another device that requires it (Write-Property). In turn, the
model of objects and services is encoded into a common language data stream representing
the desired functions or services to be performed.
Conformance Classes and the Device PICS

Since not all devices have the same level of functionality, it is important that system
designers are informed as to what objects and services are supported by which devices. This
is accomplished through the device's Protocol Implementation Conformance Statement
(PICS).
In essence PICS is a list of the features that the device supports – what objects are present and
whether the device initiates a service request (asks or commands) or executes the request
(responds or acts). This enables a like-for-like comparison to be made on different vendors’
devices in order to determine how well a BACnet product ‘fits’ a given application.
LANs
In a multi-building complex the system must necessarily comprise multiple separate networks
that interact between devices on two or more networks – not all using the same LAN
technology. To this effect, BACnet allows systems to use a variety of LAN technologies –
with each type having unique benefits and liabilities that may make it preferable in one
situation or another. Consequently, as distinct from conventional industrial networks that
only make use of the OSI 3-layer model, BACnet is based on the 4-layer model that includes
the Network layer in order to ensure interoperability between differing Data Links (Figure
9.2). OSI Layers BACnet Layers
Layer 7 Application BACnet Application Layer
Layer 3 Network BACnet Network Layer
Layer 2 Data Link IEEE 802.3 EIA 232 EIA 485

LONtalk
Layer 1 Physical ARCNET Ethernet MS/TP PTP
Figure 9.2. The BACnet four-layer model supports several data links including Ethernet.
A key feature of the BACnet network layer protocol is extensive use of specifically designed
routers that allow devices on disparate networks to communicate. This is illustrated in Figure
9.3 in which the two routers shown are used to implement the messages between the
ARCNET and MS/TP LANs – passing through both routers via the Ethernet segment in the
middle.
Figure 9.3. Extensive use of

specifically designed routers
allow devices on disparate
networks to communicate.
The BACnet four-layer model supports several data links that allows systems to use a variety
of LAN technologies:
 PTP
 MS/TP
 ARCNET
 LonTalk
 Ethernet
 BACnet/IP
PTP (point-to-point)
PTP is unique to BACnet and provides for inter-networked communications over modems
and voice grade phone lines. PTP accommodates modern modem protocols (V.32bis and
V.42) and also supports direct cable connections using the EIA-232 signalling standard.
Speed ranges from 9.6 kbaud/s to 56.0 kbaud/s.
MS/TP (master slave/token passing)

MS/TP, also unique to BACnet, makes use of a token-passing protocol, implemented in
software, and provides its own logical link control to BACnet’s network layer.
MS/TP is implemented using the EIA-485 signalling standard running on a shielded twisted-
pair (STP) wire operating at speeds from 9.6 kbaud/s to 76.8 kbaud/s.
EIA-485 transceivers are relatively inexpensive and typically found in low-cost controllers –
making this type of LAN particularly suitable for communication with unitary controller and
programmable thermostats.
ARCNET
Largely replaced by Ethernet, ARCNET (ANSI/ATA 878.1) is a token bus standard that is
still found on many heritage sites, and can run on a variety of media at different speeds –
from 150 kbit/s on EIA-485 (STP) up to 7.5 Mbit/s over coaxial cable, STP, or fibre optics.
LONtalk
LONtalk is a proprietary technology developed by the Echelon Corporation which makes use
of a proprietary chip and which requires special development tools.
BACnet/Ethernet
Providing the highest speed service within the BACnet standard, Ethernet also caters for star
topology and transformer-isolated transceivers. As distinct from conventional IP/Ethernet,
LAN addressing with BACnet/Ethernet is accomplished using the Ethernet’s media access
control (MAC) address.
 Routing over IP Internet

BACnet provides two distinct methods by which messages can traverse an IP Internet:
 IP message tunnelling
 BACnet/IP
The major distinction between these two methods is that in IP message tunnelling, the
BACnet devices do not know, or need to know, anything at all about IP, whilst in BACnet/IP
each BACnet device is actually a full-fledged IP node, complete with its own IP address.
IP message tunnelling
IP message tunnelling makes use of two different types of router: a conventional IP Router
and an Annex H Router – so called because Annexure H is where this process is defined in
the standard.
As shown in Figure 9.4, both networks are connected via a standard IP router to the Internet
at large. Now assume Device A on Network 1 wishes to send a message to Device B on
Network 2 using the BACnet network layer protocol. Device A first sends the message to the
Annex H router on its local network. The Annex H router encapsulates the BACnet message
in a User Datagram Protocol frame and sends it via IP to the Annex H router on Network 2.
When the Annex H router on Network 2 receives the IP message from its peer, it removes the
encapsulated BACnet message and sends it on to its final destination: Device B. The only
downside to this is that each message shows up twice on each network – once as a pure
BACnet message and once as an IP message.
A
Annex H BACnet BACnet BACnet
Router workstation workstation workstation
Network 1
IP
Router
Figure 9.4. Basic concept behind IP

Internet message tunnelling.
IP
Router
Network 2
Annex H BACnet BACnet BACnet

Router workstation workstation workstation
BACnet/IP
As distinct from IP Message Tunnelling, BACnet/IP devices view the IP internet as if it were
a local area network talking with each other directly over the Internet. This is illustrated in
Figure 9.5 in which Device A communicates directly with Device B without the need for
Annex H routers.
A
BACnet BACnet BACnet
workstation workstation workstation
Network 1
IP
Router Figure 9.5. BACnet/IP devices talk with
each other directly over the Internet
without the need for Annex H routers.
Internet
IP
Router
Network 2
BACnet BACnet BACnet

Addressing is carried out using a device’s IP address, which serves the same purpose as a
device’s MAC address in other BACnet networks.
The downside to the use of IP addressing is that IP routers do not normally pass along
‘broadcast’ messages, i.e., messages intended for all devices on a BACnet internetwork. This
is overcome through the use of another form of a router called the ‘BACnet Broadcast
Management Device’ (BBMD).
BBMDs act in a similar manner to the Annex H routers except that they only handle the
forwarding of broadcasted IP messages (Figure 9.6) . Since BACnet only makes use of
broadcasts infrequently, their propagation does not generally cause any problems.
A
BBMD BACnet BACnet BACnet
Network 1 Figure 9.6. BBMDs act in a similar

IP
Router manner to the Annex H Routers to
enable broadcasted IP messages to be
forwarded through the IP Routers.
Internet
IP
Router
Network 2
BBMD BACnet BACnet BACnet

BACnet Virtual Link Layer (BVL L)

The BVLL provides a set of messages that are used to deal with specific idiosyncrasies of IP
networks, e.g. the manner in which broadcasts are handled.
If the benefit is realised in that the BVLL control information can be easily extended to
encompass virtually any kind of new network technology or ‘value-added’ functions, such as
data encryption or data compression – without touching BACnet's existing application and
network layer protocols.
 BACnet summary
Some of the main benefits of BACnet include:
 No fixed architecture
 Object model is easily extended
 Large global vendor participation
 Large global user participation
 Specifically designed for building control
 No charge for its use – anyone may develop implementations without cost
Chapter 12. LonWorks
I ntroduced by Echelon in late 1990, LonWorks (Local Operating Network) is a complete

open solution for implementing interoperable control networks.
Although LonWorks has become the de facto standard in the field of building control, it has
been less successful in entering the arena of industrial control systems.
The major perceived benefit of LonWorks is that it can be used on virtually any media, wired
or wireless, and its success in building control applications is due, in part, to the ability to
make use of existing electrical wiring within the building.
Other benefits include: peer-to-peer communication; control and communication realized in a

single low-cost the chip; and the fact that it is an off-the-shelf solution complete with tools
and components, training and support, third party integration, and development expertise.
General
The traditional approach to networking has been to make use of one or another of three
different categories of control buses  sensor bus, device bus, and fieldbus.
In practice, most industrial applications include discrete and analog devices, instrumentation,
data-intensive devices, and supervisory units. As a result, most industrial applications would
thus require the use of all three types of bus.
LonWorks technology allows all forms of sensors, actuators, displays, and controllers to
communicate with one another through a common communication protocol that is shared
among all devices. Communication transceivers and transport mechanisms are standardized,
as are object models and programming/troubleshooting tools to enable the rapid design and
implementation of interoperable, LonWorks-based devices. In addition, network management
software, protocol analyzers, IP routers, PC and PCMCIA interfaces, and development tools
are all available off-the-shelf to speed development and reduce time to market.
A brief summary of LonWorks is shown in Table 12.1.
Table 12.1. LonWorks features.

Parameter LonWorks solution
Physical Connection Twisted pair, power line, EIA-232, infrared, fibre optic,
coaxial cable
Transceiver Incorporated in Neuron chip
Media Access Control CSMA/CA
Maximum number of nodes 255 (subnet/domain) x 127(node/subnet) = 32 385
ID Unique 48-bit address within Neuron chip
Message length 228 bytes
Bit rate 3 600 bps to 1.2 Mbps
Cable length 2 700m (78 kbps, bus, 64 nodes),
2 200m(78 kbps, bus ,128 nodes)
Communication service Peer-to-peer and Master/Slave
Message service Ackd, Request/Response, Unackd Repeat, Unackd
Real-time performance 8-9 ms with 10MHz Neuron Chip,
4 ms with 20MHz Neuron Chip
The Neuron chip

The heart of any LonWorks hardware device is the Neuron chip (Figure 12.1), an integrated
circuit that combines a sophisticated communications protocol, three 8-bit, in-line
microprocessors, a multitasking operating system, and a flexible input/output scheme. The
Neuron chip enables devices to send signals to, or receive signals from, each other without a
central network computer or server.
12 5 External
I/O Comms port Transformer Figure 12.1. Echelon’s
Neuron 5000 CPU chip
2-6 Serial
NVM
Memory (Courtesy Echelon)
(SPI or I2C IRQ CPU
Interface
APP CPU
RAM
(64K x 8)
NET CPU
ROM
(16K x 8) MAC CPU
Clock, Reset,
JTAG
and Service
XOUT
5
SVC
RST
XIN
The Neuron also incorporates four memory images:

The System image contains the protocol, operating system, I/O libraries etc;
The Comms image contains the communication parameters such as media type, speed, etc.
The Neurons default to differential twisted pair at the highest data rate available with the
available clock;
The Network image contains the devices logical address and binding information including
the destination node to talk to, the message types to use, etc; and
The Application image which contains the users custom control algorithms.
Physical connection
As indicated earlier, LonWorks networks are media-independent and may be operated over
long distances of twisted pair cabling, IP networks, power line carrier, fibre optic, radio
frequency, coaxial cable, or infrared media. Intrinsically safe twisted pair operation is also
supported.
Each Neuron incorporates a 5-pin configurable transceiver interface whose parameters are
stored in the Comms image. There are three different configurations for the communications
port:
 Single ended Manchester encoded – typically used for interfacing to transceivers such
as RS485.
 Differential Manchester encoded – providing a 2-wire polarity-independent interface
typically found in standard twisted pair wired transceivers. This is the default
configuration
 Special Purpose Mode – providing a two-way port to an intelligent transceiver.
Echelon uses this interface with its power line transceivers.
In addition the Neuron chip incorporates a complete onboard transceiver capable of

communicating over a twisted pair with no additional components – other than matching
resistors.
A more recent introduction is Echelon’s FTT-10 Free Topology Transceiver that supports a
twisted pair, unshielded, polarity-insensitive, peer-to-peer communications at 78 kbps. The
free topology approach allows any number of tees, stars, loops, or bus combinations in a
wiring segment – a single piece of uninterrupted wire supporting up to 64 devices. This
approach, limited to lengths of 500 m, requires a single termination module installed
anywhere on the segment.
In a doubly terminated approach, each physical end of the segment is terminated using a
termination module – with the maximum bus length determined by the wire size (e.g. 1400 m
using 22 AWG). In this approach all twisted pair wiring is carried out using a linear bus or
daisy-chain that does not support wiring tees or star connections.
This multiple-media approach allows LonWorks to be used in a wide variety of applications

that would be unsupportable if the network were limited to one or two media.
LonTalk – Media Access Control

The LonWorks protocol stack, called LonTalk, supports all seven layers of the ISO/OSI
model and is therefore well suited to multiple-media communications – allowing routing over
both LonWorks networks and IP-based networks.
The LonTalk Media Access Control (MAC) sub-layer is part of the Data link layer of the OSI
reference model and makes use of the CSMA/CA (Collision Avoidance) algorithm. The
CSMA/CA, algorithm combines the light traffic efficiency of CSMA/CD (Collision
Detection) with the heavy traffic efficiency of token-based protocols.
Like the CSMA/CD protocol, a node must first listen before it transmits (carrier sense).
However, if two or more stations collide, a jam signal is sent on the bus to notify all nodes of
the collision, to synchronize clocks, and to start contention time slots. The contention slots,
which follow the jam signal, help to avoid collisions. Each contention time slot, typically
having just over a network round-trip propagation delay time, is assigned to a particular
station and each station is allowed to initiate transmission during its contention slot.
Figure 12.2 shows a slot progression for a three-node network. When Node 2 and 3 collide, a
jam is initiated which is then followed by the contention slots. Since Node 1 has nothing to
send, Slot1 goes to idle. Node 2 starts sending its message during Slot 2. Other stations
detect the message, and stop the slot progression. After the end of the message, all nodes
initiate new contention slots. However, to ensure fairness and determinacy, the slots are
rotated to new positions after each transmission. Additionally, the priority slots, or p-slots,
can precede each slot progression to support global prioritization for high priority messages.
The network returns to an idle state when all the slots go unused.
Node 2 and 3
collide
Rotating slots
Jam P-slot Slot 1 Slot 2 Slot 3

Message P-slot Slot 3 Slot 1 Slot 2
Node 2 Message
P-slot
Node 3
Priority-slot
Time
Figure 12.2. Slot progression in a three-node CSMA/CA network.
In LonTalk, the number of slots is less than the number of stations and is varied dynamically
based on expected traffic prediction. In addition, the slot assignments are allocated randomly
to minimize collisions.
Another feature of the LonTalk protocol is guaranteed message delivery. The use of
multicast messaging with transport layer acknowledgements, ensures that all of the addressed
nodes in a group received a message.
Flexible addressing
The LonWorks addressing scheme makes it suitable for very small and very large networks
without concern about exceeding available addressing space. Subsystems can be divided
logically into domains, subnets, and groups  allowing both industrial devices and non-
industrial systems to share information yet remain distinct.
As indicated previously a single wiring segment driven by an FFT-10 transceiver supports up

to 64 nodes. However a channel can span multiple segments employing repeaters to expand
both the number of nodes and the length of the control network. In this manner the number of
nodes can be expanded up to a maximum of 32,385.
Network Variables and Types

In order to ensure interoperability amongst products from different companies, the LonTalk
protocol provides a common applications framework using Network Variables (NVs) and
Standard Network Variable Types (SNVTs).
Network Variables are used to facilitate communications between nodes on a network and
take the form of a data item that a particular device application program expects to get from
other devices on a network or expects to make available to other devices on a network.
Some nodes may send a network variable while others may receive. By only allowing links
between inputs and outputs of the same type, Network Variables enforce an object-oriented
approach to product development. Whenever a node program writes a new value into one of
its output variables, the new value is propagated across the network to all nodes with input
network variables connected to that output network variable. Examples include: zone
temperature; discharge air temperature; relative humidity; switch position; and
occupied/unoccupied mode.
All Network Variables must be interpreted in the same way. This is the role of the Standard
Network Variable Types (SNVTs) with each having standardise properties that are used to
define the variables shared on the network. These include variable context (temperature,
level, pressure) unit of measurement (°C, Volts, kPa) and dimensions (litres, litres/min).
Thus, for example, an SNVT for continuous level is defined as:
SNVT_lev_contin.
In order to allow LonWorks devices to interoperate, Network Variables (NVs) may be bound
to one another through a process called ‘binding’. Typically carried during commissioning,
output NVs may be bound to input NVs of the same data type or an output NV can be bound
to multiple input NVs.
Functional profiles
Functional profiles allow device manufacturers to publish details of their device profiles in a
standard format. A functional profile might include: network variables, configuration
properties, default behaviour, and power up behaviour. A typical example of a functional
profile for a heat pump is illustrated in Figure 4.3.
Input Network Variables

including name and Output Network Variables
Object Type and Index
SNVT type. including name and
(i.e. Heat Pump: Type 8051)
SNVT type.
nviSpaceTemp Mandatory Network nvoSpaceTemp

nv1 nv3
SNVT_temp_p Variables SNVT_temp_p
nviAppliMode nvoEffectiveSetpt
nv5 nv10
SNVT_hvac_mode SNVT_temp_p
Optional Network
nviOccCmd Variables
nv6
SNVT_occupancy
nviSetptOffset
nv7
SNVT_temp_p
Mfg-designed Network Configuration properties

Variables and types. May No49 – mclSmclHmB1 SNVT_time_secs
include proprietary non- No48 – mclRovHmB1 SNVT_time_secs
interoperable interface. No60 – mclSetpnts SNVT_temp_setpt
Device Documentation
Manufacturer
Defined Section
Explicit Messages
Figure 4.3. A typical example of a functional profile for a heat pump (courtesy Echelon).
Chapter 13. Wireless
T he use of a wireless communications in the industrial data communications arena

has generally been confined to applications where you cannot use anything else.
This would include platform-to-shore communications or transmission over very
rough terrains. Nonetheless, wireless is being increasingly used in the industrial sector.
The lure of wireless is, on the face of it, irresistible. Not only is there the direct elimination
of cabling but there is also the elimination of marshalling points, control room cabinets,
cabling systems and all associated labour costs for installing and maintaining these systems.
This represents a substantial saving.
Mobility it is another key factor. In a traditional cable linked installation, moving a

transmitter even a few tens of metres can involve considerable cost and can even interrupt
production. This problem is not encountered with wireless since it can be moved and
installed much faster than a cable-based system.
Furthermore, a wireless network infrastructure enables completely new solutions in areas

where cables cannot be used, or can only be used with limitations, due to mechanical
limitations, security requirements, or other environmental considerations.
Nonetheless, before jumping into the ‘wireless’ pond a number of issues have to be
considered – not least is the question of standards. A wireless link should entail only the
physical layer used to carry the data. It should not be concerned with physical changes to the
field instruments, the control panel, or the underlying software.
Electromagnetic radiation
Radio signals are a form of electromagnetic radiation – commonly abbreviated to EM.
Any body with a temperature above absolute zero emits electromagnetic energy as a result of
molecular thermal agitation. Depending on the kind of atom and the amount of energy, it can
take the form of infrared, light, ultraviolet, or other electromagnetic waves – differing only in
their wavelength and frequency.
Figure 13.1 is a diagram of the electromagnetic spectrum showing EM radiation extending

from just below the frequencies used for modern radio (at the long-wavelength end) through
to gamma radiation (at the short-wavelength end) progressing through microwave
frequencies, infrared, visible light, ultraviolet and x-rays.
100GHz 1GHz 300MHz 30MHz 2MHz
Gamma X-rays Ultra- Infra-red Radar UHF VHF HF
Visible
Rays violet Microwave TV TV Radio
10pm 0.1nm 1nm 10nm 100nm 0.1m 1m 10m 100m 1mm 1cm 10cm 1m 10m 100m
Figure 13.1. Diagram of the electromagnetic spectrum.
As shown, visible light extends from approximately 0.4 to 0.7 m and infrared from 0.7 to
several hundred or more micrometres. Bodies in the temperature range of 0 to 2000°C emit
nearly all their radiation in the visible and near infrared spectrum. And as the temperature of
a body is raised, both the level and spectrum of the emitted energy changes (Figure 13.2).
Solar
105
spectrum
(5800 °C)
104
103 Figure 13.2. As the temperature of a body is

Radiant emittance
Visible raised, both the level and spectrum of the

102 region emitted energy changes.
10
Glowing metal
(600 °C)
1
Human body
10-1 (37 °C)
0.4 0.8 3 5 9.3 50 100
Wavelength (m)
Generally, radio communications signals are expressed in terms of frequencies (Figure 13.3)
whilst technical microwaves and above are expressed in wavelength ( Figure 13.4).

Visible
RADIO COMMUNICATIONS AND TV (MHz)
1000 800 520 335 225 100 60 30 2

UHF (mid) UHF (low) VHF (high) VHF (mid) VHF (low) HF
960 800 520 335 225 101 100 60 59 31 30 2
Figure 13.3. Radio communications signals are normally expressed in terms of frequencies.
Visible
TECHNICAL MICROWAVES (GHz)
100 60 40 25 16 10 6 4 2.5
O V Q(Ka) K J(Ku) X C
140 60 40 26.5 18 12 8 4
Figure 13.4. Technical microwaves and above are usually expressed in wavelength.
The radio spectrum and frequency allocation

Strict regulations govern the use of various parts of the radio frequency spectrum.
Specific sections have been allocated for public use. All frequencies are allocated to users
by a government regulatory body. Table 13.1 illustrates the typical sections of the radio
spectrum allocated for public use around the world. Each section is referred to as a band.
Table 13.1. The Radio Spectrum for public use
Ultra High Frequency (UHF) Mid Band UHF 960 MHz

800 MHz
Low Band UHF 520 MHz
335 MHz
Very High Frequency (VHF) High Band VHF 225 MHz
101 MHz
Mid Band VHF 100 MHz
60 MHz
Low Band VHF 59 MHz
31 MHz
High Frequency (HF) 30 MHz
2 MHz
Certain sections of these bands will have been allocated specifically for telemetry
systems. In some countries, a deregulated Telecommunications environment has allowed
sections of the spectrum to be sold off to large private organizations to be managed, and
then onsold to smaller individual users.
Application must be made to the government body, or independent groups that hold larger
chunks of the spectrum for onselling, to obtain a frequency and no transmission is
allowed on any frequency unless a license is obtained.
The Industrial, Scientific and Medical (ISM) radio bands are reserved internationally for
license-free error-tolerant communications applications and are defined by the ITU-R in
5.138 and 5.150 of the Radio Regulations. Individual countries’ use of the bands may differ
due to variations in national radio regulations. The bands in most frequent use are:
 900 MHz band (33.3 cm) (North America, Australia and Israel)
 2.4 GHz band (12.5 cm)
 5.8 GHz band (5.2 cm)
The 900 MHz (UHF) band features excellent range (500 m or better indoors) and
wall penetration but, as indicated, is only available in a few countries. The 5.8
GHz band holds great potential in terms of higher throughput, better noise
immunity and smaller antennas. However, products are yet to be proved in the
market. As a result the 2.4 GHz band is the most widely used. Table 13.2 compares
the three main transmission technologies used at 2.4 GHz.
Table 13.2. Comparison of the three main ISM transmission technologies used at
2.4 GHz.
Standard 802.15.1 802.11b 802.15.4

(market name) (Bluetooth) (Wi-Fi) (ZigBee)
Application focus Cable replacement Web, e-mail, video Control and
monitoring
Bandwidth (kbps) 1000 to 3000 11 000 20 to 250
Transmission range 20 (Class 2) 100+ 20 to 70, 100+
(m) 100+ (Class 1) (external amplifier)
Number of supported 7 32 65 536 per network
nodes
Battery life (days) 1 to 7 ½ to 5 100 to 1000+
Power consumption 45 mA (Class 2) 300 mA 30 mA
(transmitting) < 150 mA (Class
1)
Suitability for low Poor (slow Poor (slow Good
duty cycle connection time) connection time)
applications
Spread spectrum FHSS DSSS DSSS
technology
Benefits Cost, convenience Speed, flexibility Power, cost
Transmission technology
All three of the above technologies make use of a Spread Spectrum (SS) transmission
technology that offers three main advantages over a fixed-frequency transmission:
 they are highly resistant to noise and interference;
 they are difficult to intercept; and
 they can share a frequency band with many types of conventional transmissions with
minimal interference.
As illustrated in the table above Bluetooth uses Frequency Hopping Spread Spectrum (FHSS)
whilst both Wi-Fi and ZigBee using Direct-Sequence Spread Spectrum (DSSS).
In FHSS transmission the data signal is modulated with a narrowband carrier signal that
‘hops’ in a random but predictable sequence from frequency to frequency as a function of
time over a wide band of frequencies. The signal energy is thus spread in time domain rather
than chopping each bit into small pieces in the frequency domain. This technique reduces
interference because a signal from a narrowband system will only affect the spread spectrum
signal if both are transmitting at the same frequency at the same time. If synchronized
properly, a single logical channel is maintained.
The overall bandwidth required for frequency hopping is much wider than that required to
transmit the same information using only one carrier frequency. However, because
transmission occurs only on a small portion of this bandwidth at any given time, the effective
interference bandwidth is really the same.
When using cyclic transmission, in which the transmitter uses all of the channels in a fixed
period of time, synchronisation of the transmitter and receiver is achieved by picking a
random channel and listening for valid data on that channel. The transmitter's data is
identified by a special sequence of data that is unlikely to occur over the segment of data for
this channel and the segment can have a checksum for integrity and further identification.
The transmitter and receiver can use fixed tables of channel sequences so that once
synchronized they can maintain communication by following the table. On each channel
segment, the transmitter can send its current location in the table.
Network topologies
In general there are four basic topologies: point-to-point; star; tree; and mesh.
Point-to-point
In a point-to-point network each device (e.g. Data Terminal Equipment (DTE))
communicates directly with another one – the wireless equivalent of an RS232/422
communication link (Figure 13.5).
Modem Modem
Data Terminal Data Terminal

Equipment Equipment
Figure 13.5. In a point-to-point network each device (e.g. Data Terminal Equipment
(DTE)) communicates directly with another one – the wireless equivalent of an RS232/422
communication link.
Star
The most common layout is the star network (Figure 13.6) in which a central ‘hub’ or
‘master’ provides two-way communication with it ‘nodes’ out in the field. In an Ethernet-
based network this places all of the wireless devices into the same collision domain.
Remote Remote
node node
Figure 13.6. In a star network

a central ‘hub’ or ‘master’
Remote provides two-way
node communication with it ‘nodes’
Data Remote out in the field.
collector/controller node
Remote
node
A variation on this scheme is Point-to Multipoint in which a single ‘master’ talks to several
devices simultaneously – with the master broadcasting a message and all devices and
receiving and reacting to it.
A further variation is the Multipoint-to-Point configuration in which a remote and devices

communicate their data back to a central location.
Tree
A tree topology is illustrated in Figure 13.7 and is very similar to that employed in wired
networks. Field devices are connected to a specific access point which, in turn, is connected
to another access point closer to the main base station.
Figure 13.7. In the tree topology, field devices are connected to a specific access point
which, in turn, is connected to another access point closer to the main base station.
Mesh
In a mesh network each device passes data onto its neighbour until it reaches its destination
(Figure 13.8).
Mesh networking is used in applications where the range between two points may be beyond
the range of the two radios located at those points. The mesh network allows intermediate
radios to forward messages to and from radios that are out of range. Mesh networks also have
the ability to self-heal – catering for continued communication in the event that a path should
become obstructed or even if a radio should fail.
If, for example, the radio at point C failed, a new path could be established to route messages
from A to E via D.
The real advantages of mesh networks are that they improve data reliability by providing
multiple redundant paths in areas where a lot of nodes are in use. They are not designed,
however, for every application. It takes time for paths to form and devices to associate, and
additional system delay occurs as messages must be forwarded on through the network.
Because mesh networks involve multiple paths, the network protocol must be capable of
building and maintaining routing tables to prevent messages taking ‘looped’ routes.
A
Figure 13.8. The mesh network allows
intermediate radios to forward messages
B to and from radios that are out of range.
C It also caters for continued
communication in the event that a path
should become obstructed or even if a
radio should fail.
E
D
Spread spectrum systems

In a conventional narrow-band radio (Figure 13.9), power is concentrated within a very
narrow portion of the RF bandwidth and is thus favoured by most radio communication
authorities throughout the world. However, such narrow-band radio signals are far more
vulnerable to interference by signals from identical or neighbouring frequencies.
Furthermore, because of their localised frequency, they can be relatively easily detected
and intercepted.
Tx
Serial to
Input data Frequency
parallel
signal modulator
converter
fC Figure 13.9. In a conventional narrow-

(a) band radio power is concentrated within
a very narrow portion of the RF
bandwidth.
Carrier
frequency
(b)
f
fC
This problem is overcome using a technology that is based on a concept originally

patented by the film actress Hedy Lamarr and collaborative associate, concert pianist
George Antheil, that was intended to make radio-guided torpedoes harder for enemies to
detect or jam.
Using this technology, called spread spectrum (SS), the signal is spread over a wide
noise-like band of frequencies that makes SS signals harder to detect; harder to intercept;
harder to demodulate; and harder to jam, when compared with a narrow-band signal.
Spread spectrum and transmission makes use of two different systems in which the
transmission frequencies are determined by a spreading, or hopping, sequence: Direct
Sequence Spread Spectrum (DSSS) and Frequency Hopping Spread Spectrum (FHSS).
Direct Sequence Spread Spectrum (DSSS)

Direct Sequence Spread Spectrum (DSSS) makes a use of Phase-Shift Keying (PSK) in
which the digital input modulates the phase of a reference signal (the carrier). As
illustrated in Figure 13.10 (a) a pseudo-noise (PN) generator is used to shift the phase of a
Quadrature Phase Shift Keying (QPSK) signal pseudo-randomly with a higher data rate bit
sequence, or chipping rate (RC). This divides the user data according to a spreading ratio –
spreading the data signal over the band/channel (Figure 13.10 (b)).
I Tx
Input data Serial to

PSK
signal parallel
modulator
converter
Q Figure 13.10. DSSS
modulation spreads a low level
fRF signal over a specific range of
frequencies simultaneously.
(a) PN Direct Sequence allows
generator
RF
extremely weak signals to be
recovered in the presence of
TC = 1/RC
severe electrical noise in a
(b)
direct trade-off with
transmission channel data
rate.
f
fRF - RC fRF fRF + RC
The code includes a redundant bit pattern for each bit that is transmitted – increasing the
signal’s resistance to interference. If one or more bits in the pattern is damaged during
transmission, the original data is re-sent.
This scheme requires Coherent Demodulation which is accomplished by remodulation

using a local oscillator that is at the same frequency and in-phase with the original carrier.
A variant of DSSS, called orthogonal frequency-division multiplexing (OFDM), makes

use of a large number of closely spaced orthogonal sub-carriers to carry the data. In this
manner the data is distributed over a large number of carriers spaced apart at precise
frequencies. This reduces multipath distortion and reduces RF interference. OFDM is used
with both 802.11a and 802.11g Wi-Fi systems.
Frequency hopping spread spectrum (FHSS)

Frequency hopping spread spectrum (FHSS) makes use of Frequency Shift Keying (FSK) in
which the narrowband carrier frequency is shifted pseudo-randomly in a predetermined
sequence. In this manner the carrier signal ‘hops’ from frequency to frequency as a function
of time over a wide band of frequencies (Figure 13 .11).
14 19
Figure 13 .11. FHSS
3 8 12
1 modulation transmits a data
6
10 17
4 15 signal over a number of
9 13
7 different carrier frequencies at
11 18
2 16 different times, following a
5
Power
specific pattern of frequency
(W) switching. The switching of RF
carriers may be combined with
the data packet error correction
y
nc
capability of TCP Ethernet to

ue
eq
auto-optimise a wireless network

Fr
link by taking out the ‘hops’

Time (ms) which always produce a packet
resend (Courtesy Honeywell).
With the available bandwidth divided into N channels, the transmitted signal thus occupies a
number of frequencies in time, each for a period of time (referred to as the dwell time). At
each frequency hop time, the PN generator feeds the frequency synthesiser a sequence of n
chips that dictates one of 2n frequency positions (Figure 13.12 (a) and (b)). The transmitter
and receiver follow the same frequency hop pattern.
Tx
fmod Frequency
Input data FSK
signal hopping
modulator
modulator
(a)
Figure 13.12. The available
bandwidth is divided into N
PN Frequency channels. The transmitted signal
generator synthesiser thus occupies a number of
fRF frequencies in time, each for a
period of time (referred to as the
Hop
dwell time).
Channel
(b)
1 2 3 4 5 6 7 n
f
fRF
The bandwidth is determined by the lowest and highest positions and by the bandwidth per
hop position. Because the FSSS signal is a narrow-band signal, all transmission power is
concentrated on one channel.
Comparison of DSSS and FHSS

Because data is transmitted simultaneously over every available channel, DSSS is more
powerful in multi-path rejection and throughput. However, it is also bandwidth intensive and
has to run on a much more complex and powerful Digital Signal Processing (DSP) chip since
it uses chip rates that are many times higher than the symbol rate.
FHSS on the other hand only needs to run at the symbol rate so that the chip complexity and
power consumption is lower. Furthermore, its noise immunity is better than DSSS. One
major disadvantage of FHSS is that it is slower than DSSS.
Wireless network standards

Although there has been a proliferation of different wireless communications systems, we
will in fact only be discussing six of them:
 Wi-Fi
 Bluetooth
 ZigBee
 WirelessHART
 ISA 100
 Proprietary systems
Wi-Fi
The emergence of the IEEE 802.11 standard in 1999 was to form the staple of home, business
and office networking – widely used for its high data transfer rate abilities. In the same year
the Wi-Fi Alliance was formed to certify interoperability of Wireless Local Area Network
(WLAN) products based on the IEEE 802.11 specification. (Despite efforts by the Wi-Fi
Alliance, popular convention still accepts the term Wi-Fi to mean ‘wireless fidelity’.)
Although the 802.11a was the first standard, working in the 5 GHz band with data rates of up
to 2 Mbps, a parallel activity resulted in a second standard, the 802.11b operating in the 2.4
GHz band and catering for data rates of 11 Mbps. This higher data throughput, and the
system’s low cost, led to rapid acceptance with a large installed base.
The 802.11g standard, introduced in 2003, also operates in the 2.4 GHz band but at a
maximum data rate of 54 Mbps. However, 802.11 devices operating in the 2.4 GHz band
suffer from interference from other products including: microwave ovens, Bluetooth devices,
and cordless telephones. This has led to the increased popularity of the 802.11 standard
operating in the 5 GHz band which has been upgraded for a data throughput of 54 Mbps. A
drawback of the 5 GHz band is that its effective range is slightly less than that of the
802.11b/g devices since the signals are more readily absorbed by walls and other objects in
the signal path.
Published in October 2009, the 802.11n is an amendment that improves upon the previous
802.11 standards by adding multiple-input multiple-output antennas (MIMO) and high-
density modulation (up to 64 QAM). 802.11n operates on both the 2.4 GHz and 5 GHz bands
– operating at a maximum net data rate from 54 Mbps to 600 Mbps.
Currently under development, the IEEE 802.11ac Working Group approval is expected in
early 2014 with studies indicating an estimated one billion deployment throughout the world
by 2015. Operating within the 5 GHz band this specification will enable multi-station WLAN
throughput of at least 1 Gbps and a maximum single link throughput of at least 500 Mbps.
This is accomplished by extending the concepts embraced by 802.11n: wider RF bandwidth
(up to 160 MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and even high-
density modulation (up to 256 QAM).
Further optimizations of the 802.11ac also include: up to eight spatial streams, further
increasing the data rate for each radio and beamforming to fortify RF connections.
A summary of the standards is given in Table 13 .3.
Table 13 .3. Summary of the IEEE 802.11 Wi-Fi standards.
Protocol IEEE 802.11a IEEE 802.11b IEEE 802.11g IEEE 802.11n IEEE 802.11ac
Operating frequency 5 GHz 2.4 GHz 2.4 GHz 2.4 GHz 5 GHz
5 GHz
Maximum data rate 54 Mbps 11 Mbps 54 Mbps 6 Mbps 1Gbps
Approximate 35 38 38 70 ?
indoor range (m)
Approximate outdoor 120 140 140 250 ?
range (m)
Popularity Limited adoption Widely adopted, Medium adoption, Many products, Estimated one
readily available replaced b as some based on a billion deployed
everywhere commonplace draft specification, throughout the
later world by 2015.
finalized Oct, 2009
Bluetooth
Bluetooth is named after Harald Bluetooth, King of Denmark in the late 900s, who united
Denmark and part of Norway and introduced Christianity into the region. Bluetooth is
intended to unite different technologies like cell phones, computers, PLCs, etc.
Bluetooth is a short-range wireless communications system that features robustness, low

power, and low cost. Originally developed by Ericsson in 1994, the Bluetooth Special
Interest Group was established by Ericsson, Sony Ericsson, IBM, Intel, Toshiba, and Nokia in
1998.
The physical and media access control layers of Bluetooth have been published as the IEEE
802.15.1 standard. Operating in the 2.4 GHz band, the system employs FHSS with a
frequency hopping rate of 1600 hops/s and provides a gross signalling rate of up to 3 Mbps–
with a typical maximum throughput of 2.1 Mbps. In most countries the system provides for
79 frequency channels – dependent on individual country’s frequency allocation in the 2.4
GHz ISM band.
Bluetooth defines three different power range classes covering power ranges from 3 to 100
mW and ranges from 3 to 100 m. This is illustrated in Table 13.4.
Table 13.4. Bluetooth defines three different power range classes.
Class Maximum Permitted Approximate

Power (mW) Range (m)
Class 1 100 mW 100
Class 2 2.5 mW 10
Class 3 1 mW 3
Based on a master/slave protocol, a Master Bluetooth device can communicate with up to 7

peripheral devices – with a group of up to 8 devices referred to as a piconet. A further 255
devices may be in active, or parked and can be brought into active status by the master at any
time. Two or more piconets may be connected to form a scatternet – with some devices
functioning as a bridge by playing the role of both master and slave simultaneously.
In the industrial field, Bluetooth finds its main use in cable replacement for small-packet
applications. To this effect Bluetooth has a range of different profiles, each describing how
the specifications can be used to perform a specific task e.g. headset; cordless telephony; fax;
etc. However, for most industrial applications Bluetooth is only concerned with the Serial
Port Profile (SPP) – replacing an RS232, RS422, or RS485 cable between, for example, a
PLC and a computer.
When used to replace a communication cable, Bluetooth makes use of the RFCOMM
protocol – a simple transport protocol that can, for example, emulate all nine connections of
an RS232 serial port. RFCOMM can work with two different device types. Type 1 devices
are typically communication endpoints, such as a computer or PLC, whilst Type 2 devices are
mid-points in a communication channel, e.g. a modem.
Bluetooth caters for full duplex operation by allowing each device to transmitted data
alternately – the master transmitting on even timeslots and the secondary device on odd
timeslots.
ZigBee
Centred on the Physical and MAC layers defined by the IEEE 802.15.4 for short-distance
wireless communications using DSSS, ZigBee is a low-power wireless communication
technology featuring a simplified protocol and limited functionality.
The Physical Layer consists of two layers operating in two separate frequency bands. The
lower frequency band covers both the 868 MHz European band and the 915 MHz band used
in countries such as the US and Australia whilst the higher frequency lies in the 2.4GHz
band. Because the two lower bands at 868 and 915 MHz offer only restricted bandwidths of
20 and 40 kHz respectively, the 250 kHz bandwidth (and 16 channels) offered in the 2.4 GHz
band, has made the latter the more popular choice.
The Medium Access Control (MAC) Layer is responsible for providing reliable
communications between a node and its immediate neighbours – helping to avoid collisions
and improve efficiency. The MAC Layer is also responsible for assembling and decomposing
data packets and frames.
Key features of ZigBee include:

 Data rates of 250 kbps at 2.4 GHz
 Suitable for low duty-cycle applications (< 0.1%)
 Low power consumption (battery life ranging from months to years)
 Multiple topologies (star, peer-to-peer, mesh)
 Addressing space up to 264 devices
 Addressing space up to 216 networks
 High density of nodes per network
 Low-cost
 Full handshaking protocol using CSMA/CA to minimize collision problems
CSMA/CA
In ZigBee use is made of Carrier Sense Multiple Access with Collision Avoidance
(CSMA/CA) to minimize collision problems. The basis of the Carrier Sense Multiple Access
(CSMA) protocol is that every node has access to the network and may transmit whenever
it wishes to do so. However, it must first listen on the network for a predetermined amount
of time and check for any activity. If the network is sensed to be ‘idle’ the node is then
permitted to transmit.
The essence of CSMA/CA (Collision Avoidance) is that once the network is clear, the
node first sends a signal telling all other nodes not to transmit. Only then does it send its
message.
Mesh networking
A major feature of ZigBee is that it supports mesh networking. The main advantage of a
mesh network is its ‘robustness’ since it is not dependent on the performance of any single
device on the network. It can also be thought of self-healing since, if any device is broken,
the message is re-routed around it.
ZigBee devices can be used as end devices, routers, or coordinators. As shown in Figure
13.13 a mesh network contains a single coordinator and multiple routers and end devices.
Data is passed by hopping from device to device using the most reliable communication links
until its end destination is reached.
Figure 13.13. A mesh network

Network coordinator contains a single coordinator and
multiple routers and end devices
ZigBee router (courtesy Daintree Networks).
ZigBee end device
Communication flow
Virtual links
Routes are established on demand using a route discovery process in which the originating
device broadcasts a route request command and the destination device sends back a route
reply (Figure 13 .14 (a) and (b)).
?
A A
B B
Route request
(a) (b)
Figure 13 .14. (b)Routes are established on demand using a route discovery process in
which the originating device broadcasts a route request command (a) and the destination
device sends back a route reply (b) (courtesy Daintree Networks).
Once routing table entries are established (Figure 13.15 (a)) the route may be used at will
(Figure 13.15 (b)). The routing table entry, as a minimum, records a ‘logical distance’ to the
destination and the address of the next router in the path to that destination.
A Route reply A Normal data traffic
B B
Routing table entry established Routing table entry used
(a) (b)
Figure 13.15 Once routing table entries are established (a)) the route may be used at will
(b). (Courtesy Daintree Networks).
A side benefit of mesh networking is that because data is generally only sent over short
distances, less power is required. This, coupled with the possibility of extremely low duty
cycles, can extend battery life from months up to years.
Physical layer
The Physical Protocol Data Unit (PPDU) is the total information transmitted. As shown in
Figure 13.16 the Physical layer adds the following overhead:
Preamble: 4 bytes
Start of Frame Delimiter (SFD): 1 byte
Frame Length: 1 byte
The Media Access Layer (MAC) adds the following overhead:

Frame Control: 2 bytes
Data Sequence Number: 1 byte
Address Information: 4 – 20 bytes
Frame Check Sequence (FCS): 2 bytes
The total overhead for a single packet therefore lies between 15 and 31 bytes – depending on
the addressing scheme used (Short or 64-bit addresses). Since the maximum size of a packet
is 128 bytes, the maximum data size can vary between and 97 and 113 bytes.
2 bytes 1 byte 4 to 20 bytes n bytes 2 bytes
Data
Frame Address
MAC Layer control
Sequence
information
Data FCS
Number
4 bytes 1 byte 1 byte 5 + (4 to 20) + n

Frame
Physical Layer Preamble SFD
length Media Protocol Data Unit (MPDU)
11 + (4 to 20) + n
Total packet Physical Protocol Data Unit (PPDU)
Figure 13.16. Frame construction of the Physical Protocol Data Unit (PPDU).
ZigBee PRO
In September 2007 the ZigBee Alliance announced the ratification of their new ZigBee PRO
standard. Apart from providing the platform for certifiable ZigBee products to be marketed
carrying the ZigBee logo, ZigBee PRO also brought additional functionality that includes:
 Increase network scalability to, potentially, thousands of nodes

 Increased network stability even with the close proximity of scores of networks.
 Increased network security using advanced network encryption.
 Extended power saving.
 Higher resilience through increased frequency agility.
These features make ZigBee PRO especially suited for larger applications – particularly
commercial building space.
ZigBee RF4CE
Released only last year, the ZigBee RF4CE is designed for simple home automation
applications that do not require the full-featured mesh networking capabilities of standard
ZigBee.
ZigBee RF4CE offers lower memory size requirements and the specification defines a
simple, robust and low-cost standard for implementing short range, bidirectional wireless
communications in the field of consumer electronics e.g. remote controllers.
Green Power
Green Power is a new optional feature that gives devices that are powered with ‘harvested’
energy, the ability to participate in ZigBee PRO 2012 networks. An example of harvested
energy might include, for example, a simple light switch, harvests energy from a switching
the switch on or off.
When incorporated into ZigBee PRO 2012 Green Power, this energy is captured to send an
on/off command to the network and operate the appropriate light. Since the light switches
active on the network for only an extremely brief period of time, the energy generated by the
harvester is rapidly consumed and the switch disappears from the network.
Such devices typically generate just enough power to issue their command and typically have
no other source of power or stored energy. Consequently, PRO 2012 Green Power
incorporates an extremely robust protocol that ensures high reliability even in high
interference environments.
ZigBee IP
Released only in April of this year ZigBee now provides support for IP – allowing embedded
devices (from electricity meters to light bulbs) to be directly accessed using IPv6.
Created at the behest of utilities ZigBee IP will be integrated into the next version of the
ZigBee Smart Energy profile – permitting utilities to control energy consumption.
Connecting devices such as dishwashers, lighting, and air conditioning, is another major step
in the Smart Grid concept – relinquishing control of domestic devices to the utility company
and allowing them to have better control of load shedding and compensating, for example, for
the early evening demand peak.
Suitability for industrial applications

From the foregoing it is clear to see that the essential role of ZigBee lies in the field of
residential home and office applications.
An essential characteristic that has yet to be included, and that some users claim is essential
for industrial applications, is latency determinism. As we have discussed previously, latency
is the time a message needs to travel from the source to the destination. Although the IEEE
802.1 5.4 itself offers latency through a feature called Guaranteed Time Slots, this has not,
unfortunately, been exploited by ZigBee.
WirelessHART
Published in September 2007 WirelessHART (also known as IEC 62591) is a wireless mesh
network communications protocol that adds wireless capabilities to the HART protocol
whilst maintaining backwards compatibility with existing HART devices, applications,
commands, and tools. This means that existing HART applications can use WirelessHART
without the need for software upgrades. Furthermore, WirelessHART is now field-proven,
with more than 8 000 networks (and more than 10 000 devices) working in process
applications worldwide.
Operating in the 2.4 GHz ISM band WirelessHART links use of the IEEE 802.15.4
compatible DSSS standard with channel hopping on a packet-by-packet basis.
WirelessHART uses Time Division Multiple Access (TDMA) technology to arbitrate and
coordinate communications between network devices. TDMA is a form of time-division
multiplexing where, instead of having one transmitter connected to one receiver, there are
multiple transmitters. TDMA is thus used as a channel access method that allows several
users to share the same frequency channel by dividing the signal into different timeslots.
This allows multiple stations to share the same frequency channel whilst using only that part
of the bandwidth they require.
The TDMA Data Link Layer establishes links that specifies the timeslot and frequency to be
used in communication between devices. The links are organised into super frames that
support both cyclic and acyclic communication traffic.
Network architecture
WirelessHART specifies three principal elements:
 Field Devices that are connected to the process or plant equipment
 Gateways that enable communication between host applications and field devices in the
network
 Network Manager responsible for configuration of the network, scheduling
communication between devices, management of the rounding tables, and monitoring and
reporting the health of the network
In addition WirelessHART also supports:

 Adapters that allow existing HART field devices to be integrated into WirelessHART
networks.
 Handhelds that support direct access to adjacent WirelessHART field devices.
Figure 13.17 illustrates the elements of a typical WirelessHART installation.

Plant
automation
network
l
Host application
(e.g. Asset Management)
j
i
Gateway
Figure 13.17. Elements of a
Field devices typical WirelessHART
h
g f installation (courtesy HART
Network
manager Communication Foundation).
e c
b
d Handheld
Process automation
controller
Gateway Existing HART

a device
Adapter
Time synchronized communication

Deterministic latency is the time taken for a message to travel from source to destination.
Included within the IEEE 802.15.4 is a feature called Guaranteed Time Slots. This ensures
that all device-to-device communication is executed in a pre-scheduled time window that
facilitates extremely reliable (collision-free) communication.
Each message has a defined priority to ensure appropriate Quality of Service (QoS) delivery.
Fixed time slots also enable the Network Manager to create the optimum network for any
application without user intervention.
Time synchronized communication, using 10-15 ms timeslots, also caters for accurate time
stamping – an important but often forgotten feature of several ‘wired’ FieldBus protocols.
Deterministic reliability is the ability to provide guaranteed communication between two

wireless devices – without incurring loss of packets. To diminish the impact of these packet
losses, WirelessHART provides a mechanism that allows packet losses to be evenly spread
over time, thereby making transmissions more predictable and reliable.
Application layer
To the standard command-based HART Application Layer, incorporating the Universal,
Common Practice, and Device-specific commands, is now added ‘Wireless’ commands –
providing wireless communication functionality.
Security
WirelessHART includes a robust, multi-tiered, ‘always-on’ security through the use of
industry-standard AES-128 encryption. Only trusted devices are allowed to join a network.
Such devices are identified by a ‘join key’ and through the use of standard HART identity
data (i.e. Manufacturer ID, Device Type, Tag number, etc.).
Power requirements
WirelessHART was designed specifically for low-power operation of less than 4 mA at 12 V
DC. Battery life is affected by a number of factors including environmental considerations
such as temperature. However, the single biggest major factor affecting battery life is the
update rate – how often the transmitter wakes up and takes a measurement and transmits data.
Some of the methods used to increase battery life include:
Smart Data Publishing enhances the ‘Burst Mode’ capability of the HART by generating
process data messages only when needed based on time, signal variation or crossing a user-
defined threshold.
Notification by Exception notifies users automatically when equipment needs maintenance,

a device configuration changes, or another event occurs that could jeopardize operations.
Because the information is transmitted only if such an event occurs, systems no longer need
to poll each device just to check on its health.
Multiple read commands can be made in a single transaction – catering for faster
configuration uploads.
ISA100
The fieldbus wars started as far back as 1983. The ISA was supposedly co-ordinating this
activity through the SP50 Fieldbus standard. The result was that, in the end, some 10 to
15 different industrial networking protocols were approved as ‘standards’. With the
hindsight of these wars, how could the industry not have got wireless right?
Well, they haven't! And with new standards emerging from competing vendors on almost
a monthly basis why did it take the ISA so long to finally introduce the ISA100 standard?
Too little, too late?
The ISA100 standard was ratified and finally announced, only in October 2007.
One of the challenges facing the industry lies in providing a universal solution that will allow
field I/O devices of any protocol to communicate with existing applications. To this effect,
one of the goals of the ISA100 committee is to offer support for multiple wireless
communication protocols so that both existing wired devices and new ISA100-based devices
can be configured and accessed over the wireless network. Wired devices can have their
protocol mapped to the ISA100 standard, or in some cases their messages can be
encapsulated as-is and transported over the wireless network. The ISA100-based wireless
devices can mimic wired protocols by mapping the wireless protocol to the user-chosen wired
protocol in the gateway.
ISA100.11a (to give it its full title) defines the OSI stack, system management, gateway, and
security specifications for low data rate wireless connectivity with fixed, portable, and
moving devices supporting very limited power consumption requirements. It is based on the
IEEE 802.15.4 standard operating in the 2.4GHz band with Channel hopping across 16 DSSS
channels (Figure 13.18).
5 MHz
25 MHz
Channel 1 Channel 6 Channel 11
IEEE 802.15.4
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
~25 MHz
2400 MHz 2425 MHz 2450 MHz 2475 MHz
Figure 13.18. ISA100 is based on the IEEE 802.15.4 standard operating in the 2.4GHz
band with Channel hopping across 16 DSSS channels.
Centred around the UDP/IP OSI stack the ISA 100 adds end-to-end security above UDP and
the device application, using established Internet Protocol (Running IPv6), below.
A radio mesh sits below IP – with another layer of security designed to protect the integrity
of the radio communications. The core concept is that applications do not need to be aware of
the special functions in order to communicate with wireless devices – with the wireless
aspects all encapsulated at lower layers of the stack.
Service contracts
In order to define the Quality of Service for wireless nodes to deliver a desired performance,
ISA 100 makes use of ‘Service Contracts’. A service contract is established before an
application starts transmitting. Thus, for example, if an application is configured to publish
data every 5s, the application negotiates with the network to set up a service contract to
reserve the necessary communication capacity. When a contract is granted, the applications
knows it can publish every 5 s.
Use of objects
One of the fundamental functions of the ISA 100.11a standard is the publication of process
data from a field device to a gateway (Figure 13.19) through the use of ‘concentrator objects’.
Extensions
Device Information
DD and Certification
NAMUR NE-107 Diagnostics
Client
Field Device Device
Unified Field Objects (Process)
Tag Descriptors Figure 13.19.
Filter/Hysteresis
Gateway Publication of
Alarms
Simulate (Test) General process data from a
Profiles (Process) Extensions Client field device to a
Temperature Interface
Pressure ISA100 11a Application
gateway is normally
Positioner
Etc.
User Application Process
Data
Gateway accomplished
Application
User Application Process
through
Client/server concentrator objects.
Publish/Subscribe
Alerts Security
Upload/Download
Tunnel UDP/IP UDP/IP
Application Configuration and OSI Stack OSI Stack
Management
Unified Field Objects (Generic)
Analog Input Object
Analog Output Object
Binary Input Object Service Contracts
Binary Output Object
A concentrator object is an assembly or package of various types of data in the device. These,
together with, for example, alarm reporting objects, are assembled into packets for more
efficient communications. A symmetrical object on the receiver side, called a dispersion
object, disassembles the publication when it is received (Figure 13.20). This bundling of
information conserves communication bandwidth.
ISA100.11a ISA100.11a
Analog Input Analog Input
Object Application Object Application
(Temperature) (Temperature)
Layer Layer
Gateway
Gateway
Host
Host
Analog Input ISA100.11a Analog Input ISA100.11a
Object Concentrator Object Alert Reporting
(Pressure) Object Network (Pressure) Management Network
Object
Periodic Report by
Binary Input Binary Input
Object Publication Object Exception
(Contact) (Contact)
Concentration Dispersion
Figure 13.20. A concentrator object assembles the data into packets into packets for more
efficient communications. A symmetrical object on the receiver side, called a dispersion
object, disassembles the publication when it is received.
Unified Field Objects

The ISA100 standard defines a number of objects including Analog Input Objects and
Upload/Download Objects
Analog Input Object

This 32-bit data object, using exactly the same units as Foundation Fieldbus, represents the
state of an analog input and includes a scaled floating-point number, a status, and a other
basics.
About 700 different units are defined, allowing for considerable flexibility. For example, Unit
Code 1634 is a barrel/s (US Beer).
Upload/Download Object
The Upload/Download object supports transmission of very large blocks of data and would
enable, for example vibration sensors to transmit their waveforms.
WirelessHART vs. ISA100

The bad (sad?) news for users is that after spending almost 4 years attempting to converge
WirelessHART with ISA100, the relevant sub-committee has finally abandoned its work
without finding a single convergence solution. And so it seems that the same degree of
polarisation exists between WirelessHART and ISA100 as with Marmite – you either love it
or hate it.
Where integration is required, the only alternative would appear to be to accommodate the
WirelessHART protocol through the use of a dual-gateway architecture.
There is of course no clear way of comparing the two protocols in an objective manner. The
bottom line in is that as of this moment the vast majority of instrument vendors are
supporting WirelessHART and far fewer are supporting ISA100.11a.
On the other hand, if you work with instruments from vendors such as Honeywell,
Yokogawa, GE or Yamatake then ISA100.11a would be your obvious choice.
Bibliography
[1] Andrew Nusca, ‘Majority of Americans don’t understand smart grid, study says’, March
29, 2011, http://www.smartplanet.com/blog/smart-takes/majority-of-americans-dont-
understand-smart-grid-study-says/15146?tag=search-river
[2] David Askew, ‘Raising the Grid's IQ: A Brief Introduction to Smart Grid’, Mouser
Electronics.
[3] ‘Smart grid’, http://en.wikipedia.org/wiki/Smart_grid
[4] ‘The SMART GRID: an introduction’, U.S. Department of Energy
[5] Ralph Mackiewicz, ‘Comparing IEC61850 and DNP3’, SISCO, Inc., 2005
[6] Ralph Mackiewicz, ‘Benefits of IEC61850 Networking’, SISCO, Inc., 2005
[7] Marshall DenHartog, ‘DNP3 Tutorial’, DPS Telecom, Version 1.0, August, 2012.
[8] Dr. H. Kirrmann, ‘MMS - Manufacturing Message Specifications’, ABB Research
Center, 2010
[9] ‘Integration of Substation Data’, SISCO, Inc. www.sisconet.com
[10] Gwan-Su Kim, Hong-Hee Lee, ‘A Study on IEC 61850 based Communication for
Intelligent Electronic Devices’, University of Ulsan, Korea, 2005
[11] Yingyi Liang, Roy H. Campbell, ‘Understanding and Simulating the IEC 61850
Standard’, University of Illinois, 2008.
[12 Russell Kay, ‘QuickStudy: Mesh networks’
http://www.computerworld.com/s/article/341095/Mesh_Networks August 10, 2009
[13] Bradley Mitchell, ‘Network Topologies’, About.com Guide
[14] Dick Caro, ‘Wireless Networks for Industrial Automation’, ISA, 2003
[15] ‘Q&A Certification of IEEE 802.11g’ Wi-Fi Alliance, www.wi-fi.org/
[16] ‘Bluetooth architecture - radio’, http://www.bluetooth.com/Bluetooth/Technology/
[17] ‘ZigBee Technology: Wireless Control that Simply Works’, Patrick Kinney, Kinney
Consulting LLC, 2003
[18] John Schwartz, ‘What’s in the ZigBee protocol and 802.15.4?’, The Industrial Wireless
Book.
[19] ‘The OSI Model‘, http://vigna.cimsi.cim.ch/tai/BDC/in/BDC31.html
[20] George Thomas, ‘Introduction to the Internet Protocol’, The Extension, Volume 1, Issue
4, Contemporary Controls, Winter 1999.
[21] Gary C. Kessler, ‘An Overview of TCP/IP Protocols’, 29 December 2004,
kumquat@sover.net
[22] ‘Understanding IP Addressing: Everything You Ever Wanted To Know’, 3Com, 2004
[23] ‘Classless Inter-Domain Routing (CIDR) Overview’, Pacific Bell Internet Services,
1999
[24] George Thomas, ‘Introduction to the Transmission Control Protocol’, The Extension,
Volume 1, Issue 5, Contemporary Controls, March-April 2000.
[25] ‘Transmission Control Protocol’, http://www.scit.wlv.ac.uk
[26] Adolfo Rodriguez, John Gatrell, John Karas, Roland Peschke, ‘TCP/IP Tutorial and
Technical Overview’ IBM Redbooks, 2001
[27] ‘Port Numbers’, http://www.iana.org/assignments/port-numbers
[28] Charlie Schluting, ‘Networking 101: Understanding Spanning Tree’, August 27, 2008
http://www.linuxplanet.com/linuxplanet/tutorials/6520/1
[29] ‘VLAN Information’, http://net21.ucdavis.edu/newvlan.htm
[30] Stelios Antoniou, ‘How to Prevent Loops with STP: Spanning Tree Protocol’,
http://www.trainsignal.com/blog/spanning-tree-protocol-tutorial
Bibliography 134
[31] ‘Rapid Spanning Tree Protocol’, Hill Associates,

http://www.hill2dot0.com/wiki/index.php?title=Rapid_Spanning_Tree_Protocol
[32] ‘MSTP Technology White Paper’, Hangzhou H3C Technologies Co., Ltd., 2007
[33] ‘Understanding Multiple Spanning Tree Protocol (802.1s)’, Document ID: 24248,Cisco
Systems, Inc., 2007.
[34] Deon Botha, ‘Multiple Spanning Tree Protocol’, http://networkninja.co.za/cisco-
systems/multiple-spanning-tree-protocol/
[35] ‘Understanding Multiple Spanning Tree’,
http://etutorials.org/Networking/Lan+switching+fundamentals/Chapter+10.+Implementing+a
nd+Tuning+Spanning+Tree/Understanding+Multiple+Spanning+Tree/
[36] ‘The Multiple Spanning Tree Protocol’, 802.1Q – 2003, University of New Hampshire
Interoperability Laboratory.
[37] David Fisher, ‘How BACnet is Changing Building Automation Networking’, PolarSoft
Inc., 2007.
[38] H. Michael Newman, SSPC Past Chairman, ‘BACnet - A Tutorial Overview’.
[39] Michael Volz, ‘Modbus-TCP: The quiet success story’ Control Engineering, Europe
June 1, 2003.
[40] George Thomas, ‘Connecting BACnet devices to an IP infrastructure’, Contemporary
Controls, 2009.
[41] ‘LonWorks, A Plan For Product Enhancement’, Real Time Automation Inc.

Complete Smartgrid Handbook Version 5

Uploaded by

Copyright:

Available Formats

You might also like

Complete Smartgrid Handbook Version 5

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Complete Smartgrid Handbook Version 5

Uploaded by

Copyright:

Available Formats

An introduction to

Copyright © Michael A. Crabtree M.Sc.

No part of this publication or associated software may be copied, reproduced, transmitted or

And lastly, I reserve my right to spell according to the British system:

In 1966 he moved to South Africa where he was involved in the sales of

Mick holds a Masters Degree from the University of Huddersfield.

Chapter 1. Introduction to the Smart 1

And then there’s the ‘Smart Grid’.

What’s a Smart Grid?

So what exactly is it?

It might be said that the primary function of a

 Integrated communications, connecting components to open architecture for real-time

substation automation asset management, equipment monitoring, wide-area monitoring and

T he physical layout (or topology) of a network is usually implemented as one of four

Node 1 Node 2 Node 3 Node 4

Daisy chain NODE NODE

Tree NODE NODE

Figure 2. 2. Daisy chain; mainline/trunkline; and tree configurations.

Ring (or Loop) topology

Figure 2.4. In the ring topology all of the

IEEE 802.3 frame 64 to 1518 bytes

7 bytes 1 byte 6 bytes 6 bytes 2 bytes 46 to 1500 bytes (Optional) 4 bytes

Figure 3.1. The IEE 802.3 format.

Preamble and SFD

Medium access control

Figure 3.4 (e + f). Collision

Station A produces Jamming signal

Collision Range of random Back-off time

This is called a Truncated Binary Exponential Back-off Algorithm where binary

Now, let’s see what could happen.

Hubs and switches

Network Interface Network Interface Network Interface

Figure 3.6. Since the switch

Single collision domain

Switch Switch Switch

It is important to recognise that communication within a single collision domain is half-

Switch Segment 3 with

Virtual LANs (VLANs)

IEEE 802.1q VLAN tag 64 to 1522 bytes

7 bytes 1 byte 6 bytes 6 bytes 4 bytes 2 bytes 46 to 1500 bytes 4 bytes

Tag type VLAN

Figure 3.13. 4-byte VLAN tag according to IEEE 802.1p/q.

Let’s deal with the two most important fields first:

Priority Code Point (PCP)

The remainder of the tag is structured as follows:

Transmission Control Protocol (TCP); and

OSI MODEL ARPA MODEL

TCP UDP SERVICE OR

TCP Header Application Data Transport Control

IP Header TCP Header Application Data Internet Protocol

Ethernet Ethernet Network Interface

Internet Protocol – general overview

Up to IP Options (often zero)

The fields contained in the header, and their functions, are:

Internet Header Length (IHL)

Type of Service (ToS)

Type of Service (TOS)

Precedence TOS Unused