Hybrid Wired-Wireless Networks for Real-Time Communications

8/19/2019 Hybrid Wired-Wireless Networks for Real-Time Communications

1/13

Incorporating the Best of Both Worlds for

Improved Functionality in Industrial Environments

Thanks to their pecu-

liar features, wireless

networks are currently

becoming more and

more attractive for use

in industrial automa-

tion and manufactur-

ing scenarios. However, they cannotbe thought of as a total replacement

for more traditional wired networks

in such environments, at least in the

short/mid term. This means that for

the time being it is worth focusing on

their integration with the existing in-

dustrial wired solutions, in order to

achieve enhanced flexibility, efficien-

cy, and performance for the overall

networked system.

In this article, some considerations

are presented about the way sev-eral well-known industrial networks

(based on both fieldbus and industrial

Ethernet solutions) can be practically

extended with wireless subnetworks

that rely on popular technologies,

such as IEEE 802.11 and 802.15.4. This

results in hybrid networks, which are

able to combine the advantages of

both wired and wireless solutions. Inparticular, advantages and drawbacks

of several interconnection techniques

are highlighted and, depending on the

wired networks specifically taken into

account, some hybrid configurations

that are able to cope in a satisfactory

way with the tight timing require-

ments often imposed by industrial

control systems are suggested.

Overview

Recent years have witnessed the everincreasing adoption of digital com-

munication networks in manufactur-

ing environments. Field networks

(also known as fieldbuses) [1] are

certainly the most popular solution in

those scenarios. For a long time they

have been used at the lowest levels

of factory automation systems (shop

floor), which are often characterized

by severe timing requirements. On

the other hand, Ethernet networks,

which were traditionally employed as

factory backbones in order to handleinformation flows between different

8 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008 Digital O bject Identifie r 10.1109/MIE.2008.917155 1932-4529/08/$25.00©2008IEEE


2/13

MARCH 2008 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 9

GIANLUCA CENA,ADRIANO VALENZANO,AND STEFANO VITTURI

plant areas, are now deemed suitable

also for control applications down to

the field level. This is mostly due to

enhancements of the network perfor-

mance, which led to the development

of industrial Ethernet protocols pur-

posely designed to provide real-time

communications [2]. In many cases,

variants of such protocols have been

defined that are able to support iso-

chronous communications as well.

However, the scenario mentionedabove is quickly evolving, and other

types of communication technolo-

gies, namely wireless networks, are

currently widely available at reason-

able prices. Wireless communica-

tions technologies are becoming more

and more pervasive everyday, and

they are changing deeply several as-

pects of human life by enabling new

perspectives and opportunities that

could hardly even be thought of only

a few years ago. This is likely going to

become true for industrial and factoryenvironments, too, where highly auto-

mated production systems can get sig-

nificant benefits from the introduction

of the most advanced wireless com-

munication techniques. Indeed, sev-eral studies have recently proved the

suitability of some of the most popular

wireless solutions for employment in

industrial scenarios as well, including

real-time communications [3].

Adopting wireless communications

in industrial environments is particu-

larly attractive as it allows, in princi-

ple at least, the avoidance of cabling,

which in many applications turns out

to be cumbersome and/or expensive.

However, while several standard solu-

tions and components are commonly

available for wired industrial com-

munications, wireless systems are far

from being considered well settled for

such kinds of applications. In fact, it is

worth pointing out that the straightfor-

ward introduction of highly innovative

solutions in industrial and manufac-

turing systems has never been either

simple or fast. This is due to several

reasons, such as reliability, efficien-

cy, safety, cost, and security, just to

mention a few. As a consequence, the

growth of wireless technologies in in-

dustrial applications is expected to be

noticeably slower than in other areas,

even though they are envisaged to play

a crucial role in many next-generation

industrial and production systems.

A point most experts agree on is

that wireless communications are un-

likely to be able to replace completely

the current wired solutions adoptedin many industrial scenarios, at least

© PHOTODISC & ARTVILLE


3/13

10 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n MARCH 2008

in the mid term. Indeed, it is worth

noting that in many practical appli-

cations, this is not considered a real

need. Actually, in factory automation

systems there is often the need to

connect a few components to an al-

ready deployed wired communication

system that cannot be reached (eas-

ily and/or reliably) with a cable. The

most common example is a sensor

mounted on a moving/rotating device

that has to be connected to a control-ler located on a wired segment.

This kind of problem may be eas-

ily solved by providing wireless ex-

tensions to existing wired systems.

Resulting configurations are hybrid

networks in which, typically, wireless

segments have limited geographic

extension (some tens of meters) and

connect only a few stations. Moreover,

controllers are usually located on the

wired segment in such networks. This

implies that wireless (sub)networks

will have to coexist with more tradi-

tional wired communication systems

for quite a long time. Thus, the inte-

gration of wireless and wired com-

munications in industrial scenarios

is becoming a crucial issue that has

to be dealt with carefully in order to

achieve efficiency and performance.

This article focuses on the most

relevant aspects concerning the

aforementioned hybrid networks. In

particular, after a general analysis

of hybrid wired/wireless systems,

the ways wireless extensions of both

fieldbuses and real-time Ethernet

(RTE) networks can be effectively

implemented are taken into account.

Then, examples will be provided of

extensions based on some popular

networks. Specifically, we refer to the

well-known Profibus DP [4] and Devi-

ceNet [5] fieldbus networks, as well

as the Ethernet/IP [6] and Profinet IO[7] RTE networks. (In the latest ver-

sion of the Profinet specification, the

acronym IO has been removed. None-

theless, for practical reasons, in this

article we maintain the original nota-

tion.) It is worth noting that many oth-

er interesting solutions actually exist

that could be provided with a wireless

extension. However, as it would have

been practically unfeasible to deal

with all of them, we decided to focus

on a reduced set of networks that are

nevertheless representative of a widerrange of industrial solutions.

On the other hand, we consider

both the IEEE 802.11 wireless lo-

cal area network (WLAN) [8] and

the IEEE 802.15.4 low-rate wireless

personal area network (LR-WPAN)

[9] as possible wireless extensions.

Indeed, 802.11 WLANs have been al -

ready considered in several studies

and tested in practical applications

that demonstrated their suitability

for industrial use [10]–[12]. For such

a reason, most of the examples pro-

vided in this article are based on

that solution. However, it has to be

noted that 802.15.4 LR-WPAN is an

emerging standard for short-range

connectivity, characterized by long

battery lifetime and low cost. Such

features allow one to implement, for

example, sensor networks distribut-

ed over wide geographical areas and

the connection of sensors/actuators

located on mobile equipment.

As a further possible network

candidate for implementing wireless

extensions, it is worth mentioning

Bluetooth [13]. This network, which

was originally designed as a mere

cable replacement system, has pro-

gressively gained widespread use

thanks to its features, and it is now

employed in several areas, including

industrial automation. For example,

in [14] a real -time wireless sensor/ac-tuator system based on Bluetooth is

described. That system, which uses a

modified version of the original me-

dia access control (MAC) protocol,

has been implemented and its com-

ponents are currently available as

commercial products. However, de-

spite its interesting features, due to

the same practical reasons outlined

above for the wired networks (it is ac-tually impossible to consider all the

available solutions here), we are not

discussing Bluetooth in this article.

Relevant Industrial NetworksThe basic operating principles of the

networks we are going to consider in

this article are briefly discussed in the

following sections.

Profibus DP and Profinet IO

Profibus and Profinet are the maincommunication solutions foreseen by

the Profibus and Profinet International

(PI) community for industrial environ-

ments, each of which is, in turn, made

up of several profiles.

Profibus DP is a widespread field-

bus based on a master-slave ap-

proach, implementing data exchange

between controllers (masters) and

field devices such as sensors and

actuators (slaves) at the maximum

speed of 12 Mb/s. (Actually, the Pro-

fibus DP standard specifies a mas-

ter-master communication as well.

Nonetheless, this is typically meant

for the nonreal-time exchange of di-

agnostic and/or parameterization

data. As such, this type of communi-

cation will not be further considered

in this article.) At the data-link layer,

the medium access is granted exclu-

sively to master stations via a token

passing scheme. It is worth mention-

ing, however, that most practical con-

figurations make use of a single mas-

ter (monomaster networks). Slave

devices can only respond when que-

ried by a master. The operation of the

network is based on a polling cycle of

slaves that is repeated continuously

by the master. At each query of a de-

vice, the master provides the slave

with output data and, at the same

time, fetches the input data. Suitable

techniques are also available for thetransmission of acyclic data.

Another issue that should be taken into account

when interconnecting industrial Ethernet networks

and WLANs concerns the mechanisms for broadcast/

multicast traffic confinement.


4/13


Profinet IO, instead, is an RTE net-

work included in Part 2 of the IEC 61784

International Standard [15]. In par-

ticular, the communication profile CP

3/6 of such a standard refers to both

Profinet IO RT_Class 2 and 3 specifi-

cations, whereas the communication

profiles CP 3/4 and CP 3/5 both are

concerned with Profinet IO RT_Class1. As specified by the standard, some

different types of stations may be con-

nected to the network, with the most

significant of them being I/O control-

lers (e.g., PLCs or industrial PCs) and

I/O devices (sensors and actuators).

Basically, Profinet IO makes use

of a time division multiple access

(TDMA) technique to guarantee fast

and precise access to the transmis-

sion medium. In practice, the traffic

scheduling takes place according tothe cycle shown in Figure 1. The cycle

is divided into four phases. In the first

one (RED) only RT_CLASS 3 traffic

(the most critical) can take place and

over predefined physical paths en-

forced by a special kind of switches

purposely developed for Profinet IO.

In the ORANGE phase, only RT_CLASS

2 frames are exchanged. In this case,

however, physical paths are not de-

fined. The GREEN phase is reserved

to both RT_CLASS 2 and RT_CLASS 1

frames, either cyclic or acyclic. In this

phase (which is the only mandatory

one) access to the physical medium is

regulated by the priority assigned to

the frames, according to IEEE 802.1Q

[16]. Finally, the YELLOW phase is

used for nonreal-time traffic.

Similarly to other RTE networks de-

fined by the IEC 61784 standard, the ap-

plication layer protocol of Profinet IO

is based on the definition of communi-

cation objects that can be exchanged

over the network via communication

relationships established between I/O

controllers and I/O devices.

DeviceNet and Ethernet/IP

DeviceNet and Ethernet/IP (together

with ControlNet and CompoNet) rely

on the well-assessed common indus-

trial protocol (CIP) [17]—formerly

known as the control and informa-

tion protocol—which enables a highdegree of interoperability among

these kinds of networks. Figure 2 de-

picts the protocol stack foreseen by

CIP. Seamless bridging and routing

is supported natively by this proto-

col, which enables parameterization

information and process data to be

easily exchanged in heterogeneous

distributed systems that employ

both fieldbus and industrial Ether-net transmission technologies.

DeviceNet adopts the control-

ler area network (CAN) protocol at

the lower layers of its protocol stack

(physical and data link). Despite the

bus topology and the relatively low

speed (up to 500 kb/s), it is able to

guarantee deterministic behavior

thanks to the bitwise arbitration tech-

nique featured by CAN. This protocol,

in fact, implements a nonpreemp-

tive priority-based communicationsystem, which does not suffer from

destructive collisions and where the

message with the highest priority is

always given precedence. This also

means that network congestion is im-

plicitly prevented.

Instead, Ethernet/IP is conceived

to rely on conventional Ethernet

transmissions. Even though strictly

deterministic operations are not

granted, the Open DeviceNet Vendor

Association (ODVA) (the organization

that is in charge of managing CIP) has

established a set of design rules [18]

that achieve quasi real-time behavior

in Ethernet/IP. Basically, they require

that switched high-speed Ethernet

is adopted (i.e., full duplex 100-Mb/s

equipment) and that unnecessary

network traffic is kept as low as pos-sible (e.g., by means of virtual LANs

(VLANs) to confine multicast traffic

generated as a consequence of pro-

cess data exchanged over I/O connec-

tions according to the producer/con-

sumer model). As long as the load

on the network is (fairly) below the

theoretical available bandwidth, non-

blocking switches guarantee that any

message is eventually delivered to the

intended destination within a period

of time that, because of the high bitrate, is short enough for most control

applications (at least from a practical

point of view).

IEEE 802.11

The IEEE 802.11 family includes sever-

al standard specifications for wireless

local area networking. All devices be-

longing to such a family (also referred

to as WiFi) work in specific bands of

the radio spectrum, centered around

FIGURE 2 – Protocol stack of CIP-based networks.

TCP/UDP

IP

Ethernet

IEEE 802.3

WiFi

IEEE 802.11

DeviceNetConnectionManager

Encapsulation Protocol

CAN

ISO 11898

CIP (Explicit Versus I/O Messaging)

Device Profiles and Application ObjectsUser Layer

Application

Layer

Transport

Layer

Data-Link

and PhysicalLayers

FIGURE 1 – Profinet IO cycle.

Red

RT_Class 3

Orange

RT_Class 2

Green

Class 2/Class 1

Yellow

Nonreal Time


5/13


either 2.54 GHz (legacy 802.11, 802.11b,802.11g) or 5 GHz (802.11a). Very

high data rates are foreseen in the

802.11 standard, ranging from 11 Mb/s

(802.11b) to 54 Mb/s (802.11g/a). More-

over, they are expected to increase up

to (about) one order of magnitude with

the next-generation devices (802.11n).

The IEEE 802.11 standard specifies

a mandatory distributed coordination

function (DCF) to access the physical

medium, based on the use of a carrier

sense multiple access with collisionavoidance (CSMA/CA) technique. As a

further, nonmandatory, option, 802.11

encompasses also a centralized MAC

protocol [point coordination function

(PCF)]. In this case, the access to the

network is regulated by a specific sta-

tion, namely, the point coordinator

(PC), which grants exclusive access to

any wireless station, thus preventing

collisions (the main cause of nonde-

terminism in WLANs). Although PCF

is not currently supported by the vast

majority of commercial WiFi boards, it

nevertheless represents an interesting

option for industrial applications, at

least from a theoretical point of view.

Finally, it is worth mentioning that

devices complying with the 802.11e

standard also support the concept of

quality of service (QoS) in the form of

traffic prioritization/parameterization.

Such a property is particularly appeal-

ing for industrial applications since it

allows (at least in principle) for faster

delivery of critical messages. In partic-

ular, the 802.11e specification defines

an additional hybrid coordination

function (HCF), which in turn consists

of two distinct mechanisms; namely,

the enhanced distributed channel ac-

cess (EDCA) and the HCF controlled

channel access (HCCA). Despite HCCA

being able to provide a fairly more

deterministic behavior than EDCA,

thanks to the presence of a hybrid co-ordinator (HC) that effectively ensures

contention-free access to the wirelessmedium by allocating stations trans-

mission opportunities (TXOPs), com-

pliant devices are, at the time of writ-

ing, not available yet. EDCA-compliant

equipment, instead, is currently avail-

able off the shelf at (relatively) low

cost. EDCA is noticeably simpler and

cheaper than HCCA, as it basically re-

lies on a distributed approach. Hence,

it will likely be adopted more and more

in several real-world wireless indus-

trial installations.

IEEE 802.15.4

The IEEE 802.15.4 specification deals

with ad-hoc wireless interconnections

of electronic devices within a limited

transmission range (some tens of me-

ters) at low data rates (up to 250 kb/s).

It has been designed in order to target

several application fields ranging, for

example, from home and building au-

tomation to simple cable replacement

and from smart tags to automotive

sensing. Devices of the IEEE 802.15.4

family typically operate in the indus-

trial, scientific, and medical (ISM)

band, centered around 2.4 GHz (actu-

ally, a second band is also available,

depending on the country considered,

but it is not widely adopted since it is

limited to data rates of 20 kb/s).

Two types of MAC protocols are en-

compassed by the standard: a beacon-

enabled MAC protocol, characterized

by the presence of a network coordina-

tor that periodically sends beacons, and

a nonbeacon MAC protocol. Most of the

commercially available devices operate

in beacon-enabled mode. In this mode,

the network coordinator periodically

issues superframes that are divided in

two parts. The first part, called conten-

tion access period (CAP), takes place

immediately after the beacon and is

based on a distributed CSMA/CA mech-

anism for controlling the access to thechannel. After the CAP, there might be a

(optional) contention-free period (CFP),

in which guaranteed time slots (GTSs)

are exclusively allocated to the nodes.

Conversely, in the nonbeacon mode a

pure CSMA/CA protocol is adopted for

channel access control. In this way, a

totally decentralized and asynchronous

MAC is obtained.

Implementationof Hybrid NetworksFrom a general point of view, the in-

terconnection of different communi-

cation networks is achieved through

specific devices called intermediate

systems (ISs) [19]. These devices have

different structure, functionality, and

complexity, depending on the layer

of the open systems connection (OSI)

reference model they operate.

Interconnection at the Physical Layer

The simplest form of ISs are repeaters.

They operate at the physical layer and

are used to interconnect subnetworks

that share the same MAC mechanism.

They are usually adopted for regenerat-

ing electrical signals flowing across dif-

ferent network segments. In Ethernet

networks, for example, they operate

according to the so called 3-R princi-

ple: reshaping, retiming, and retrans-

mitting. In this way, it is possible to face

the problem of signal attenuation over

the cable when the network extension

grows longer. Moreover, they enable an

increase in the number of nodes that

can be networked, which is practically

limited by the current absorbed by de-

vices attached to the bus.

Besides simpler two-ported de-

vices, a special kind of repeater exists

(called a hub) that is provided with

several ports and can be adopted to

achieve star network topologies. Be-

cause of the increased reliability (a

defective cable no longer affects the

whole network operation), hubs are

particularly suitable for deploying

network infrastructures and for the

cabling of buildings. More advanced

versions of repeaters may be some-

times employed to interconnect sub-

networks that rely on different media

(e.g., copper wires and fiber optics)

or signaling techniques (e.g., voltage/current levels).

Highly automated production systems can get

significant benefits from the introduction of the most

advanced wireless communication techniques.


6/13


As the MAC mechanism that regu-

lates the access to the shared transmis-

sion medium is the same for the whole

network, care has to be taken about the

increased propagation delays when net-

work segments are connected through

repeaters. In many cases, such as Eth-

ernet, CAN, or Profibus networks, this

leads to limitations on the maximumnumber of repeaters that can be insert-

ed between any two nodes.

An interesting example of hybrid

wired/wireless interconnection car-

ried out at the lowest layer of the pro-

tocol stack is provided in [20]. In that

case, the authors refer to a hybrid ar-

chitecture between Profibus and Ra-

dio Fieldbus [10]. Both networks use

the same data-link layer protocol—

specifically, the fieldbus data link (FDL)

defined by Profibus—but have differentphysical layer protocols. Indeed, Profi-

bus is based on the well-known RS-

485 standard whereas Radio Fieldbus

uses a direct spread spectrum (DSS)

technique similar to the one adopted

in 802.11 WLANs. However, it is worth

noting that pure repeaters are unusual

in real-life hybrid wired/wireless net-

works since the resulting physical com-

munication support in most practical

cases is not seen as a (sufficiently) uni-

form medium by the MAC protocol (the

access techniques adopted by wireless

networks are, typically, rather different

from wired solutions).

Interconnection at the

Data-Link Layer

An IS operating at the data-link layer

is called a bridge. Its function is to

transfer frames between systems

that are not (or cannot be) treated

as a uniform communication support

by protocols at the MAC level (e.g.,

switched LANs that are made up ofseveral separate collision domains).

A bridge that is equipped with more

than two ports is commonly referred

to as a switch (this kind of devices

is currently present in almost every

real-life Ethernet installation).

Even though the MAC mechanism

does not need to be the same for all the

subnetworks interconnected through

bridges/switches, the set of communi-

cation services they provide at the data-

link layer should be similar. Limitationson the kind of networks that can be

interconnected concern, for example,

their addressing scheme (which should

be uniform on the whole network) and

the maximum transfer unit (MTU),

which affects the allowed payload size

as fragmentation is not permitted at the

data-link level. When subnetworks with

different MTUs are interconnected, care

has to be taken so that the payload of

the exchanged frames never exceeds a

threshold equal to the minimum among

the supported MTUs.

Figure 3 shows an example of inter-

connection through a bridge for the

hybrid networks considered in this

article. From a practical point of view,

the bridge to be used in hybrid wired/

wireless networks is a device equipped

with two transmitting/receiving inter-

faces (one for each subnetwork) and,

optionally, a protocol converter. A

frame originated from whatever seg-

ment (either the wired network or thewireless extension) is propagated to

the other by the bridge, which receives

the frame, converts it in the suitable

(target) format, and then retransmits

it. Access points (APs) are a very popu-

lar example of a bridge for hybrid net-

works. APs are used both to enable

communication in an infrastructure

WiFi network [also known as a basic

service set (BSS)] and to interconnect

it to an existing Ethernet backbone

(portal function).

Interconnection at Higher Layers

For ISs working at the network layer or

above, the generic term of gateway is

often adopted. A gateway is responsi-

ble for transferring protocol data units

(PDUs), as well as generic streams of

information and application services

between the application processes

of the interconnected systems, by

performing the required protocol

translations. From a general point of

view, there is no practical restriction

on the kinds of networks that can be

interconnected through gateways.

FIGURE 3 – Interconnection via a bridge.

Data-Link Protocol Converter

Wired

Network

WirelessExtension

Bridge

(Access Point)

Physical

Data Link

Network

Transport

…

Application

Application

Program

Physical

Data Link FrameFrame

Transceivers Physical

Data Link

Network

Transport

…

Application

Application

Program

Physical

Data Link


7/13

On the other hand, gateways are usu-

ally quite complex, expensive devices,

and the performance they achieve is

somehow lower than bridges (higher

latencies have to be expected).

ISs that operate specifically at the

network layer are known as routers.

At this level, a uniform addressing

scheme and protocol are used [i.e., theinternet protocol (IP)], which ensure

worldwide connectivity regardless of

the physical medium, MAC mecha-

nism, and data-link services of the in-

terconnected subnetworks. However,

we are not directly interested in them

since most industrial networks are de-

ployed as local networks.

When the interconnection takes

place at the application layer (conver-

sion of high-level services), the term

proxy is sometimes adopted. Indeed,a proxy is more than an application-

layer gateway. It usually represents

parts of the network as if they were a

single node, possibly hiding the under-

lying structure for security or perfor-

mance reasons. For instance, proxies

are used in fieldbus/IP connections

to represent legacy fieldbus segments

(as in Profinet).

An example of a wireless extension

implemented at the application layer is

shown in Figure 4. As can be seen, the

gateway incorporates two interface

boards fully compliant with the over-

all protocol stacks of the subnetworks

they are connected to, and a protocol

converter, usually implemented as a

software application.

General Issues Concerning

Wireless Extensions of

Wired Industrial Networks

Although technically feasible, wire-less extensions of industrial networks

to be used at the shop floor (either

fieldbuses or RTE networks) are not

so straightforward. This is basically

due to three main reasons.

First, the transmission support (wire-

less medium) is shared among all the

nodes. Even operating at the maximum

allowable speed (e.g., 54 Mb/s for cur-

rently available 802.11a/g/e networks),

this may result in a low per-station net

throughput compared to that of wirednetworks (especially switched Ethernet)

when the number of connected devices

grows higher. Furthermore, the non-

negligible overheads introduced by the

communication protocol (larger proto-

col control fields, acknowledgement and

reservation mechanisms, no provision

for full-duplex operations, etc.) have

to be considered as well. For example,

the minimum time taken to exchange

reliably 8 B of user data over a WLAN (54

Mb/s, no RTS/CTS, no TCP/IP encapsu-

lation, ad-hoc network mode) including

interframe spaces (as they effectively

waste network bandwidth) is about 100

µs. Such a value is only slightly shorter

than the transmission time over a CAN

network operating at 1 Mb/s.

Second, random access techniques

(e.g., CSMA/CA) are often employed

by wireless networks. This means

that, on the one hand, unpredictable

(and unbounded) transmission delaysmight occur (because of the occur-

rence of repeated collisions) while,

on the other hand, network conges-

tions could be experienced, and this

is surely the worst aspect. In other

words, when the offered load exceeds

a given threshold (even for a limited

time), a condition may likely arise be-

cause of positive feedback so that the

effective net throughput decreases as

the load increases. This means that

the network may become temporarilyunavailable to carry out timely data

exchanges, which is not compatible

with proper operation of distributed

control systems. Moreover, even in the

case of lightly loaded networks, non-

negligible jitters may affect the trans-

mission unless some form of prioritiza-

tion scheme is suitably adopted.

Third, and last, wireless chan-

nels are much more error prone than

wired cabling [21], and this is a seri-

ous drawback when they are used

in industrial environments, which

are usually affected by nonnegligible

FIGURE 4 – Interconnection via a gateway.

Application Protocol Converter

WiredNetwork

WirelessExtension

Gateway

Physical

Data Link

Network

Transport

…

Application

ApplicationProgram

Transceivers Physical

Data Link

Network

Transport

…

Application

ApplicationProgram

Physical

Data Link

Network

Transport

…

Application Services

Physical

Data Link

Network

Transport

…

Application

Controllers

TCP/UDPIP



8/13

electromagnetic interferences. Besides

causing higher communication laten-

cies and jitters, transmission errors

also directly affect the network reliabil-

ity and, consequently, the robustness

of the overall system. Unless acknowl-

edged transmission schemes are ad-

opted (which, incidentally, are not pos-

sible when broadcast and producer/consumer-like multicast traffic are

taken into account), there is a nonneg-

ligible chance that messages sent over

the air never reach the intended des-

tination. This may also cause consis-

tency problems; i.e., when a multicast

message is received only by a part of

the addressed devices.

Each one of the three drawbacks

mentioned above can be tackled (at

least partially) by means of already

existing or soon to be available tech-nologies. In particular, the throughput

problem could be somehow lessened

by the upcoming 802.11n specification,

which is based on the multiple-input

multiple-output (MIMO) technology

and is theoretically able to provide

a big leap (about one order of mag-

nitude) in the network throughput. A

more reasonable (and viable) choice,

however, could be the use of several

(smaller) separate wireless subnet-

works (e.g., WLANs), interconnected

by means of a wired backbone in or-

der to limit the packet rate on each

one of them. Keeping the size of each

wireless subnetwork small also helps

in operating it at higher speeds (be-

cause of the automatic rate adaptation

mechanism featured by most APs and

WLAN adapters).

The second problem (determin-

ism) can be dealt with through the

adoption of specific medium access

techniques; e.g., PCF in the case of

IEEE 802.11. Unfortunately, PCF is sel-

dom implemented in commercially

available APs. Variants of PCF, such

as the iPCF mechanism introduced by

Siemens [22], have the big drawback of

being proprietary solutions, and hence

compatibility and interoperability can

hardly be ensured. Alternatively, the

new prioritization features offered

by the 802.11e standard (already sup-

ported by several WLAN adapters cur-rently available off the shelf) could be

exploited [23]. While not guaranteeing

strict determinism, such a technology

(originally developed for multimedia

traffic) is able to provide significant

improvements that might often be

enough for many industrial systems.

For example, it is possible to ensure

quasi-real-time behavior by assign-

ing higher priorities to the messagescharacterized by tight timing/safety

constraints. Also TDMA techniques

may be employed to solve the deter-

minism problem. In such a direction,

for example, the guaranteed time slots

provided by IEEE 802.15.4 represent

an interesting opportunity.

The third problem (robustness) can

be faced in several ways. Whenever

possible, a proper placement of anten-

nas is envisaged, optionally by exploit-

ing antenna diversity. In the case thatthis is not enough, leaky wave anten-

nas [24] can be used to ensure reliable

communication over radio links. The

drawback in this case is the need to

deploy the leaky cable infrastructure,

which makes it a nonuniversal solu-

tion. As an alternative, if true mobility

is required, devices operating in the

5-GHz band (802.11a) can be adopted

as a satisfactory choice [21]. In this

way, in fact, interferences with other

devices (mobile phones, Bluetooth-

enabled equipment, notebooks with

wireless connections, etc.) operating

in the standard (and already jammed)

2.4-GHz ISM band are avoided.

IEEE 802.11-BasedExtensions: FieldbusesTypically, the transmission protocols

adopted by fieldbuses are noticeably

different from those employed bywireless networks at all levels of the

communication stack. For example,

random access techniques typical of

WLANs are not employed by any field-

bus network to the best of our knowl-

edge. Other problems may arise that

are related to either the frame pay-

load, which in fieldbuses is typically

very small, or the addressing scheme.

As a consequence, wireless exten-

sions of fieldbuses have to be imple-

mented mainly at the applicationlayer; i.e., through gateways. However,

some remarkable exceptions exist.

DeviceNet, for instance, provides in-

teroperability with all the networks

based on the CIP protocol thanks to

some interesting routing techniques

that allow, in principle, implementing

extensions at a lower level (i.e., through

direct routing of CIP messages).

Extension of Profibus DP

Figure 5 shows that the gateway

needed to extend Profibus DP can be

FIGURE 5 – Gateway with proxy functionality.

DPProto-

col

Profibus DP

IEEE

802.11

Gateway (Profibus DP Master Station)

GatewayCode

InputBuffers

WirelessProtocol

OutputBuffers



9/13

implemented directly on a Profibus DP

master station. An 802.11 board has to

be installed on the master as well, and

suitable code has to be developed for

this particular implementation in or-

der to enable the exchange of data be-

tween the two segments. The wireless

nodes implementing the extension are

organized in a basic service set (BSS)

which, as specified in the IEEE 802.11

standard, is the basic building block

of a WLAN. A similar solution hasbeen proposed in [11] for the former

version of Profibus; namely, Profibus

FMS. In that paper, some useful results

derived from a set of practical experi-

ments are provided. In particular, the

stations of the BSS, which periodically

exchange 40 B, are handled via a vir-

tual polling algorithm with a resulting

cycle time of 5 ms.

In order to limit the effects of the

delays that are unavoidably introduced

by the gateway, the use of a proxy is

recommended. The proxy hosts a pro-

cess image (decoupled from the wire-

less segments) that can be accessed

from the wired side at any time, with-

out timing restrictions introduced by

the wireless communication protocol.

This is accomplished, as shown in

Figure 5, by means of a set of I/O buf-

fers. Stations on the wireless segment

access these buffers in order to store

the input data acquired from the con-

trolled system. In the same way, output

data written by the proxy into the out-

put buffers are subsequently retrieved

by the wireless stations.

The proxy code is responsible for

interfacing the Profibus DP protocol

to the input/output buffers (it is worth

noting that buffers and data caching,though reasonable for a proxy, from a

general viewpoint are not sufficient). In

detail, when a data exchange requests

that carries output data is issued over

the DP protocol, the proxy code ex-

tracts data from the DP protocol data

unit, writes them into the output buf-

fers, and then generates the acknowl-

edgment for the DP protocol. At the

same time, input data are taken from

the input buffers and returned to the

requester through the DP protocol.

Note that the above technique

does not impose any restriction on

the protocol(s) actually used on the

wireless extension (e.g., as already

mentioned, a virtual polling algorithm

is used in [11]), as data exchanges take

place via I/O buffers.

Extension of DeviceNet

DeviceNet was designed bearing in

mind the option of having several sub-

networks interconnected by means of

routers. Such a feature, besides making

the interconnection with other ODVA

networks (e.g., ControlNet and Ether-

net/IP) simpler, turns out to be very

helpful when implementing wirelessextensions. Routing in heterogeneous

CIP networks is achieved by means of

so-called port segments, which are

added to messages and explicitly de-

scribe the route they should follow

(this is often referred to as source

routing). Such a route is specified by

means of a list of items. Each item, in

turn, describes a hop by means of the

output port of the router to be used in

forwarding the message and the ad-

dress of the intended destination inthe next subnetwork (either the target

node or another router). As the frame

travels along its route, the port seg-

ment is shortened by routers, as each

one of them removes the information

concerning the hop it has processed.

Obviously, the routing process takes

some time, and, hence, response times

over the interconnected network grow

longer. This aspect has to be taken

into account carefully when demand-

ing real-time applications have to be

designed (e.g., it might be necessary

to relax timing constraints).

Using WLANs together with con-

ventional DeviceNet devices can be

accomplished in several ways. The

first, and simpler, solution is to rely

on a DeviceNet to Ethernet/IP router

that, in turn, is connected to a conven-

tional AP (see Figure 6). In this case,

no new hardware component has to

be developed. However, this solution

causes each message to traverse (at

least) two intermediate devices before

reaching its target node (e.g., the rout-

er and the AP), and this introduces ad-

ditional delays.

A second and more sophisticated

solution requires the modification of

existing DeviceNet routers so as to

include an 802.11 port, as shown in

Figure 7 (this should not be a dif ficult

task for manufacturers of DeviceNet

products). In this case, the routeris completely aware of the exactFIGURE 6 – Extension of DeviceNet via a CIP router and an AP.

IEEE802.11

RequestingDevice

DeviceNet toEthernet/IP

RouterAP

TargetDevice

Ethernet/IPDeviceNet


The integration of wireless and wired

communications in industrial scenarios is becoming

a crucial issue that has to be dealt with carefully in

order to achieve efficiency and performance.


10/13

requirements of each CIP connection,

and, hence, it can select the most suit-

able QoS when forwarding messages

over the radio channel (provided

that a QoS-enabled network, such as

802.11e, is adopted), thus providing

better real-time behavior.

It is worth noting that currently

some devices are actually availableoff the shelf that can be used to intro-

duce wireless extensions to DeviceNet

networks. For instance, [25] describes

a solution that relies on the routing of

messages for carrying out information

exchanges over explicit connections.

Such a solution foresees a wireless

master (implemented as a DeviceNet

slave) connected to the primary

DeviceNet bus, and one or more wire-

less slaves (which are seen as virtual

DeviceNet masters), each one con-necting a different DeviceNet remote

bus. To improve communication ef-

ficiency, process data collected by

wireless slaves from each remote bus

can be provided to the master as a sin-

gle process image. Unfortunately, solu-

tions like this are mostly based on pro-

prietary communication technologies,

and, hence, they cannot be considered

as universal proposals.

IEEE 802.11-Based Extensions:Real-Time Ethernet NetworksDespite the availability of both hard-

ware components and protocols, the

implementation of wireless extensions

to RTE networks is not immediate. In-

deed, interoperability between Eth-

ernet and WLANs is always ensured

by using inexpensive off-the-shelf

devices (i.e., APs), along with some

commonly available protocols. As an

example, the IEEE 802.1D bridging

protocol [26] allows for interconnec-

tions at the data-link layer; however,

such a solution, which has good effi-

ciency, is sometimes difficult to imple-

ment since it relies on the availability

of IEEE 802.2 logical link control (LLC)

services, which are not always explic-

itly accessible on Ethernet and 802.11

off-the-shelf components.

A more straightforward intercon-

nection technique can be obtained via

the TCP/IP protocol suite but, unfor-tunately, it is unsuitable for achieving

real-time behavior. For this reason, in

some cases the User Datagram Proto-

col (UDP) protocol [27] is preferred.

UDP, in fact, has lower overheads than

TCP and offers simpler access to com-

munication thanks to its unacknowl-

edged transmission scheme (which

lacks the sliding window mechanism).

In this case, however, the weakpoint is found in the access protocols

adopted by RTE networks, which often

are not completely compliant with the

original Ethernet specifications. For

example, Ethernet Powerlink (EPL)

[28], which actually relies on standard

Ethernet controllers, adopts a protocol

based on a fast and precise periodic

polling carried out on (wired) nodes

that ensure rapid operation (cycle time

under 200 µs) and ultra-low jitter (be-

low 1 µs). Unfortunately, this does notallow for the integration of wireless

devices, due to the unavoidable uncer-

tainty of communication times over

radio channels (because of interfer-

ences and electromagnetic noise) that

impairs determinism unacceptably.

Extension of Profinet IO

The extension of Profinet IO has to

face all the problems discussed in the

previous sections. Indeed, it is not

possible to implement an extension at

the data-link layer, since the CSMA/CA

technique employed by IEEE 802.11

cannot cope with the very tight time

schedule imposed by the TDMA medi-

um access technique used by Profinet

IO. Consequently, the extension may

only be implemented at the applica-tion layer, via a gateway, in a way simi-

lar to that described for Profibus DP.

There are, however, two alterna-

tive options for carrying out such

a task. When real-time behavior is

not required, data exchange with

the wireless nodes may simply take

place in the nonreal-time period of

the Profinet IO cycle (the YELLOW

phase shown in Figure 1). The second

option is more appealing, since it en-

ables preserving real-time properties,and is based on the use of the PCF. As

shown in Figure 8, an AP implement-

ing the PCF technique can be used as a

bridge. With such a solution, wireless

stations can be included in the Profi-

net IO cycle, too, since the AP is able

to assign them specific time slots that

provide contention-free (and, hence,

deterministic) access to the wireless

medium. Specific actions should be

FIGURE 7 – Extension of DeviceNet via a WLAN-enabled CIP router.

IEEE802.11

DeviceNet

to WLANRouter

DeviceNet

TargetDevice

Requesting

Device


FIGURE 8 – Extension of Profinet IO via a bridge.

ProfinetIO

Interface

IEEE802.11

APwith

PCFProfinet IO

Bridge


11/13

taken in this case so as to improve net-

work reliability as well (e.g., by means

of leaky cables).

An example of an application based

on this technique is described in [29]

(actually, the iPCF technique men-

tioned earlier in this article is used).

In [29], 21 Profinet IO devices are lo-

cated on a wireless segment, whereasthe Profinet IO controller relies on

wired connections. The bridge is a

commercial product [22] implement-

ing iPCF.

Extension of Ethernet/IP

As long as Ethernet/IP networks are

taken into account, there is no theo-

retical need for any change to adapt

the CIP protocol to 802.11 networks.

In fact, APs can be used that trans-

parently forward each message tothe intended destination by means of

its Ethernet address (which, in turn,

is derived from the IP address used

at the application level), as shown in

Figure 9. While this is certainly the

most appealing (and inexpensive)

solution, it might lead to suboptimal

results when real-time process data

have to be exchanged. This is because

in the existing conventional 802.11b/g

WLANs, priorities cannot be enforced

for process data higher than those

for background traffic, unless special

techniques, such as those provided by

802.11e, are adopted.

In the latter case, however, existing

implementations of CIP are likely to

be modified in order to map the tim-

ing constraints of each message (I/O

versus explicit connection, expected

packet rate, and so on), which are

known at the application level, onto

the most suitable QoS as provided by

the underlying communication sys-

tem. From this point of view, Ethernet

is not the same as 802.11e WLANs. In

fact, IEEE 802.1Q [16] enables specify-

ing up to eight traffic classes to encode

frame priority in switched Ethernet,

whereas 802.11e foresees four differ-

ent access categories (ACs) to provide

traffic prioritization.

It is worth noting that developingWLAN-enabled Ethernet/IP devices,

such as the target node on the right

side in Figure 9, is not really a difficult

task. The advantage of adopting this

kind of solution is that the device can

exploit the knowledge about the timing

requirements of the CIP connection to

select the most suitable QoS. A viable

choice could be, for example, to map

I/O connections with tight timing re-

quirements (i.e., high expected packet

rate) on voice-grade (AC_VO) traffic,whereas those having less severe con-

straints on the transmission times can

be mapped on video-grade (AC_VI)

transmissions. Finally, explicit con-

nections devoted to parameterization

can rely on either best-effort (AC_BE)

or background (AC_BK) traffic.

In the case where conventional

APs are used to interconnect wired

Ethernet/IP segments with wireless

extensions, exploiting 802.11e QoS

becomes more difficult. Indeed, it is

impossible for a conventional AP to

determine the priority of each frame,

since it is defined at the application

layer, whereas the AP operates at the

data-link layer. A possible solution is

to rely on APs that are able to map

802.1Q traffic classes directly onto

IEEE 802.11e ACs (and vice versa).

Besides traffic prioritization, an-

other issue that should be taken into

account properly when interconnect-

ing industrial Ethernet networks and

WLANs concerns the mechanisms

for broadcast/multicast traffic con-

finement (process data are usually

exchanged according to the producer/

consumer paradigm). In wired net-

works such as Ethernet/IP, this is dealt

with by means of VLANs. Although

this mechanism is not available in

802.11 wireless networks to reducethe amount of multicast traffic, some

devices are currently available off the

shelf that can map VLANs to different

service set identifiers (SSIDs) [30].

Such a feature is quite interesting,

as it can be used to ease the integra-

tion of WLAN extensions to existing

Ethernet/IP networks.

IEEE 802.15.4-Based ExtensionsIn analogy with the networks defined

by the IEEE 802 committee(s), the IEEE802.15.4 specification only refers to the

lower two layers of the communication

stack and does not specify any type of

upper-layer protocol. Thus, in order to

grant access to 802.15.4 networks by

the higher layers, two options are rec-

ommended by the standard:

using LLC type 1 services [31]

accessing MAC services directly.

Both techniques can be employed

profitably, even if it is worth men-

tioning that LLC services are seldom

made available by 802.15.4 board

manufacturers.

Due to the limited transmission

speed of IEEE 802.15.4, the resulting

hybrid networks are not generally

able to provide (very) fast communica-

tions. On the other hand, the 802.15.4

protocol has good efficiency, especial-

ly when compared to 802.11. Finally,

the guaranteed time slots made avail-

able in the beacon-enabled mode al-

low a co-ordered (e.g., deterministic)

access scheme to the shared medium

by wireless nodes, with a consequent

reduction of the jitters that typically

affect pure CSMA/CA protocols.

Extension of Fieldbuses

The use of IEEE 802.15.4 for implement-

ing wireless extensions of fieldbuses

basically presents the same problems

already discussed for IEEE 802.11-

based extensions. In particular, theremarkable differences between the

■

■

FIGURE 9 – Extension of Ethernet/IP via an AP.

IEEE802.11eAP

Ethernet/IP

Target

DeviceRequesting

Device



12/13

MAC protocols of the two kinds of

networks do not practically allow for

the interconnection at the lower lay-

ers. Thus, from the above consider-

ations it follows that fieldbus exten-

sions based on 802.15.4 networks can

only be achieved through a gateway

that translates the services foreseen

by the application layer of the field-bus to calls to 802.15.4 services. The

gateway is typically implemented as

a station that embeds the interface to

the wired fieldbus and, at the same

time, acts as network coordinator for

the 802.15.4 system.

Similarly to the case of the extension

of Profibus DP through IEEE 802.11, also

in this case there are no restrictions on

the protocol(s) actually employed over

the wireless extension. Indeed, the gate-

way may either use the 802.15.4 data-linklayer services (LLC or MAC) directly or,

alternatively, it may rely on the func-

tions provided by a proprietary proto-

col explicitly defined for managing data

exchanges over the wireless extension.

Once again, note that significant ben-

efits may be obtained by the use of

the guaranteed time slots. As an ex-

ample, the virtual polling algorithm

described in [11] for 802.11-based ex-

tensions does not need to be imple-

mented from scratch for IEEE 802.15.4

since, in practice, such a mecha-

nism is natively provided by the

beacon-enabled mode of the access

technique.

Extension of Real-Time Ethernet

Concerning RTE networks, the avail-

ability of the 802.15.4 LLC protocol

could enable, in theory, the imple-

mentation of extensions right at the

data-link layer, since most RTE net-

works provide access to such a layer

as well. However, it has to be con-

sidered that LLC type 1 services are

nonconfirmed, connectionless ser-

vices. Such a feature may represent

a serious drawback, which could lead

to a decrease of the overall system

performance due to the nonnegligible

probability of errors affecting com-

munications in the wireless segment.

In fact, since 802.15.4 does not imple-

ment frame retransmission at theMAC level, a (possible) corruption of

a frame cannot be recovered by the

LLC type 1 services (because they are

unconfirmed) with the consequent

definitive loss of the related protocol

data unit. This means that also in this

case an effective extension can only

take place via a gateway.

Finally, it is worth mentioning that

ZigBee [32] offers a complete proto-

col stack based on IEEE 802.15.4 and,

obviously, represents an interesting

opportunity for implementing hybridnetworks when the wired segment

consists of either a fieldbus or an

RTE network. In particular, it is inter-

esting to notice that ZigBee enables

connectivity with whatever type of

network based on the IP protocol

by means of the purposely defined

ZigBee expansion devices (ZEDs).

As a consequence, it is possible (at

least in principle) to interface easily

with some RTE networks (basically,

all those that allow for TCP/IP com-

munication, such as, for example,

Ethernet/IP and Profinet IO) via a

conventional IP router.

ConclusionIt is envisaged that network configu-

rations resulting from wireless exten-

sions of conventional (wired) indus-

trial networks will be adopted more

and more in the near future, thanks to

the availability of wireless technolo-

gies and devices able to cope with in-

dustrial communication requirements

properly. Concerning wired networks,

the analysis presented above focused

on two popular fieldbuses (Profibus

DP and DeviceNet) and two RTE net-

works (Profinet IO and Ethernet/IP),

since they are based on different

protocols. In the same way, both the

IEEE 802.11 family of WLAN standards

and IEEE 802.15.4 wireless sensor net-

works were taken into account as wire-less extensions, as they are two of the

most promising technologies for in-

dustrial and control applications, and

many devices are already available off

the shelf at (relatively) low cost.

As pointed out in the article, the

extension of Profibus DP and, in gen-

eral, of almost all fieldbuses, can

typically take place at the applica-

tion layer. While providing greater

flexibility, this may worsen the over-

all performance, due to the delays

gateways unavoidably introduce. Asan interesting exception, DeviceNet

can be interconnected at a lower

layer via CIP routers. This means

that in hybrid networks based on

DeviceNet all devices can be seen

(and accessed) as conventional CIP

nodes, whereas in the case where a

gateway/proxy is adopted (as hap-

pens in Profibus DP) wireless nodes

are no longer effectively part of the

Profibus network.

When real-time (industrial) Eth-

ernet networks have to be provided

with a wireless extension, more

alternatives are possible, in prin-

ciple, including interconnection

at the data-link level. However, as

these networks often rely on pecu-

liar protocols to ensure predictable

communications over Ethernet,

the integration with WLANs is not

straightforward. As a consequence,

a loss of performance/determinism

in hybrid networks may occur also

in this case. Moreover, when 802.11

is selected for the wireless exten-

sion, the native randomness of the

DCF medium access technique has

to be taken into account carefully

in the design of the hybrid network,

as it can give rise to additional (and

unwanted) delays. Significant im-

provements in this direction could

be achieved by using deterministic

techniques such as, for example, PCFin WLANs (which, however, is not so

The IEEE 802.15.4 specification deals with ad-hoc

wireless interconnections of electronic devices within

a limited transmission range (some tens of meters)

at low data rates (up to 250 kb/s).



13/13

frequently available in real devices)

or guaranteed time slots in 802.15.4

networks (which, however, suffer

from a noticeably lower bit rate).

Finally, an interesting option for

achieving quasi-real-time communica-

tions is also offered by the IEEE 802.11e

standard, which supports the concept

of QoS. Indeed, it has been shownthat, as an example, traffic prioritiza-

tion could be used to deal with differ-

ent types of messages (and, hence,

of timing requirements) defined and

handled by the CIP protocol, so as to

transparently enable control applica-

tions to meet real-time constraints

even when hybrid interconnections

are adopted.

Biographies

Gianluca Cena is director of researchwith the Istituto di Elettronica e di

Ingegneria dell’Informazione e delle

Telecomunicazioni of the Italian Na-

tional Research Council (IEIIT-CNR),

where he is engaged in activities con-

cerning communications in manufac-

turing and automotive environments.

He is the author of many technical

papers in the area of computer com-

munications. His current research

interests include industrial commu-

nication systems and protocols and,

in particular, real-time networks. He

is also active in the international sci-

entific community operating on these

subjects, and he served as program

cochairman for the sixth and seventh

editions of the IEEE Workshop on Fac-

tory Communication Systems.

Adriano Valenzano is director of

research with the Istituto di Elettron-

ica e di Ingegneria dell’Informazione

e delle Telecomunicazioni of the Ital-

ian National Research Council (IEIIT-

CNR), where he is responsible for re-

search on computer communications

and formal methods for the analysis

of security-critical systems. He is

the author/coauthor of about 200 pa-

pers published in international jour-

nals, books, and conferences in the

area of computer engineering. He is

an associate editor of the IEEE Trans-

actions on Industrial Informatics. He

has also served as a general cochair-man for the Sixth IEEE International

Workshop on Factory Communica-

tion Systems. His research interests

concern computer communications

(in particular, industrial communi-

cations) and the formal analysis of

security-critical systems.

Stefano Vitturi received the Lau-

rea degree (summa cum laude) in

electronics engineering from Univer-sity of Padova, Padova, Italy, in 1984.

He has been a senior researcher with

the Istituto di Elettronica e di Ingeg-

neria dell’Informazione e delle Tele-

comunicazioni of the Italian National

Research Council (IEIIT-CNR) since

January 2002. His research interests

include industrial real-time communi-

cation networks (wired and wireless)

and implementation and performance

analysis of devices conforming to the

most popular industrial communica-tion protocols. In the context of these

activities, he is an expert of the IEC

SC 65 Standardization Subcommittee,

and he has been the scientific respon-

sible of the Italian Profibus Compe-

tence Center.

References[1] J.P. Thomesse, “Fieldbus technology in indus-

trial automation,” Proc . IEEE , vol. 93, no. 6, pp.1073–1101, June 2005.

[2] J.D. Decotignie, “Ethernet-based real-time and

industrial communications,” Proc . IEEE , vol.93, no. 6, pp. 1102–1117, June 2005.[3] A. Willig, K. Matheus, and A. Wolisz, “Wireless

technology in industrial networks,” Proc. IEEE ,vol. 93, no. 6, pp. 1130–1150, June 2005.

[4] Prof ibus-DP Standard, Translation of the German National Standard DIN 19245 Part 3 , DeutschesInstitut fuer Normung, 1994.

[5] Low-Voltage Switchgear and Controlgear— Controller-Device Interfaces (CDIs)—Part 3: DeviceNet , IEC Standard 62026-3, July 2000.

[6] Open DeviceNet Vendor Association, EtherNet/ IP Adaptation of CIP, Edition 1.3 (CIP NetworksLibrary, Vol. 2). Ann Arbor, MI: ODVA, 2007.

[7] PROFIBUS International, “Application layerprotocol, application layer services for decen-tralized periphery and distributed automa-tion, specification for Profinet,” ver. 2.2, Oct.

2007.[8] IEEE Standards for Information Technology—

Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Par t11 Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) Specifications, IEEEStandard 802.11-2007, June 2007.

[9] IEEE Standard for Information Technology— Telecommunications and information exchangebetween systems—Local and metropolitanarea networks—Specific requirements—Part15.4: Wireless Medium Access Control (MAC)and Physical Layer (PHY) Specifications for Low—Rate Wireless Personal Area Networks(WPANs), IEEE Standard 802.15, Sept. 2003.

[10] L. Rauchhaupt, “System and device architec-ture of a radio based fieldbus—The RF Field-

bus system,” in Proc . IEEE WFCS 2002 , Vast-eras, Sweden, Sept. 2002.

[11] S. Lee, K.C. Lee, M.H. Lee, and F. Harashima,“Integration of mobile vehicles for automatedmaterial handling using Profibus and IEEE802.11 networks,” IEEE Trans. Ind. Electron.,vol. 49, no. 3, pp. 693–701, June 2002.

[12] A. Willig, M. Kubisch, C. Hoene, and A. Wolisz,“Measurements of a wireless link in an industri-al environment using an IEEE 802.11-compliantphysical layer,” IEEE Trans. Ind. Electron., vol.49, no. 6, pp. 1265–1282, Dec. 2002.

[13] Bluetooth Special Interest Group, [Online].Available: www.bluetooth.com

[14] D. Dzung, J. Endresen, C. Apneseth, and J.-E.Frey, “Design and implementation of a real-time wireless sensor/actuator communicationsystem,” in Proc. IEEE ETFA 2005 , Catania,Italy, pp. 433–442, Sept. 2005.

[15] Indust rial Communication Networks—Part 2: Additional Fieldbus Prof iles for Real-Time Net- works Based on ISO/IEC 8802-3 , IEC Standard61784-2, Dec. 2007.

[16] IEEE Standard for Local and Met ropolitan Area Networks Vir tual Bridged Local Area Networks ,IEEE Standard 802.1Q-2005, 2006.

[17] Open DeviceNet Vendor Association, Common Indust rial Protocol (CIP) Specif ication, Edition3.2 (CIP Networks Library, Vol. 1). Ann Arbor,MI: ODVA, 2007.

[18] Open DeviceNet Vendor Association, Network

Infrastructure for EtherNet/ IP: Introduction andConsiderations (publication no. PUB00035R0).[Online]. Available: http://www.odva.org/Por-tals/0/Library/Publications_Numbered/PU-B00035R0_Infrastructure_Guide.pdf

[19] F. Halsall, Data Communications, Computer Networks and Open Systems. Reading , MA:Addison Wesley, 1996.

[20] C. Koulamas, S. Koubias, and G. Papadopoulos,“Using cut-through forwarding to retain thereal-time properties of Profibus over hybridwired/wireless architectures,” IEEE Trans. Ind. Elect ron., vol. 51, no. 6, pp. 1208–1217, Dec.2004.

[21] D. Brevi, D. Mazzocchi, R. Scopigno, A. Boniven-to, R. Calcagno, and F. Rusinà, “A methodologyfor the analysis of 802.11a links for safety-critical

industrial communications,” in Proc. IEEE WFCS2006 , Torino, Italy, pp. 165–174, June 2006.

[22] Siemens AG, “SCALANCE W788 RR AccessPoint” [Online]. Available: www.automation.siemens.com/net

[23] G. Cena, I. Cibrario Bertolotti, A. Valenzano,and C. Zunino, “Evaluation of response timesin industrial WLANs,” IEEE Trans. Ind. Infor- mat., vol. 3, no. 3, pp. 191–201, Aug. 2007.

[24] G. Baumann, “Controlling the wireless field,” Indust . Wireless Book, vol. 9, no. 3, June 2006.

[25] OMRON, (2002, Sept.) WD30-ME/-SE/-ME01/-SE01 DeviceNet Wireless Units—OperationManual. [Online]. Available: http://www.om-ron.com/

[26] Media Access Control (MAC) Bridges , IEEE Stan-dard 802.1D, June 2004.

[27] User Datagram Protocol , DARPA Standard RFC768, Aug. 1980.

[28] Ethernet Powerlink Standardization Group,“Ethernet Powerlink communication profilespecification,” ver. 2.0, 2003.

[29] G. Santandrea, “A Profinet IO applicationimplemented on wireless LAN,” presented at6th IEEE Int. Workshop on Factory Communica- tion Systems (Industry Day), Torino, Italy, June2006. (Slides available: http://wfcs2006.ieiit.cnr.it/)

[30] 3Com. (2006, June 19). 3Com Wireless 776011a/b/g PoE Access Point User’s Guide. [On-line]. Available: http://www.3com.com/

[31] Logical Link Control (with amendments 3, 6and 7), IEEE Standard 802.2, 1998.

[32] The ZigBee Alliance (2006, Dec.) “ZigBee specifi-

cation,” [Online]. Available: www.zigbee.org/en/spec_download/zigbee_downloads.asp

Documents

Hybrid Wired-Wireless Networks for Real-Time Communications