The extensive Siemens Industrial Wireless LAN portfolio is developed with a focus on scalable low latency and highest reliability keeping automation solutions in mind. This can be achieved by choosing the right hardware, using the right functionality – the so called iFeatures like iPCF/iPCF-MC for wireless real-time communication, even for safety applications.

This article covers the top 5 considerations for a network architect who wants to make full use of the benefits from Industrial Wireless LAN in an industrial automation solution.

Top 5 questions

I am very thankful for the people being in discussion with me, from network architects at manufacturers, smaller business solution providers, Siemens partners, architects of university networks and others.

These are the main questions, which I want to tackle in this blog:

What do I need to consider forextending and scaling up a network?
What about interoperability with other WLAN devices?
What about co-existence with other WLAN networks?
How does iPCF/iPCF-MC work in detail?
Any considerations with regards to network security?

What do I need to consider for scaling up?

IEEE 802.11 (commonly known as WLAN or Wi-Fi) is prone to unpredictable maximum latency per client as soon as the number of (connected) devices is going up.

Having this in mind, scaling an automation network solution offers in general the following challenges:

maintaining real-time with a high number of clients
scaling configuration
maintaining visibility of the application

Easy calculations and thousands of proven applications in the field give me the confidence to easily recommend the right solution.
Honscheid, Ben; Senior Presales Consultant (Siemens)

Real–time: The reachable latency of iPCF protocol depends on the number of clients used.

iPCF and iPCF-MC give you scalability in terms of usable channels for time critical roaming process, no matter how many channels are used in the application.

The protocol also let’s you calculate the possible reliable maximum latency dependent on the maximum number of clients at one AP.

Configuration: The more devices, the more to configure and maintain. And the more human errors in copy-pasting parameters or running self-build scripts.

The devices themselves offer an easy-to-use UI (user interface: Web based management), CLI capabilities and specials like a PRESET-PLUG functionality. The latter enables a very simple “PLUG-in and start it up”.

The SINEC NMS Network Management System in team play with SCALANCE offers a central policy based configuration possibility for the Access Points and Client Modules. For scaling up to even bigger numbers of devices in an application this management system is the go-to.

Follow the link below to dig deeper into the capabilities of the network management system:

https://new.siemens.com/global/en/products/automation/industrial-communication/sinec-networkmanagement/sinec-nms-network-management-system.html

Visibility: The more devices, the harder to diagnose it in case you want to troubleshoot a certain behavior.

One part of the answer is SINEC NMS. SINEC NMS gives you the visibility of the network and its topology. It also works as your central syslog server to receive all logs and traps from your network devices.

The other part of the answer are the devices themselves. They log relevant information. Functionalities like a bidirectional signal recorder or a remote capture possibility help to look down to the bit level of situations.

What about interoperability with other WLAN devices?

Interoperability shall be defined as: communication between a device speaking iPCF or iPCF-MC and a device speaking standard WLAN, read: IEEE 802.11.

As iPCF is a proprietary protocol, it is only supported by the respective Siemens SCALANCE W devices.

A device speaking iPCF or iPCF-MC will not connect to a standard wireless LAN device or vice versa.

The benefit from iPCF is real-time communicatio. This can only be maintained if all devices that connect to the network and interact with the Access Point use the same protocol. Therefore the connection with non-iPCF devices is not possible as this would have a negative effect on the real-time communication.

This is a bit comparable to bringing in IEEE 802.11n (Wi-Fi 4) devices into an IEEE 802.11ax (Wi-Fi 6) network. All the advantages of the newer standard disappear, as they can not be used for that dedicated device.

How is iPCF/iPCF-MC working in detail?

The following videos give you a good idea in less than 3 minutes per video:

iPCF (2:02 minutes)

https://assets.new.siemens.com/siemens/assets/api/uuid:4513b9f0-37d0-4a32-aa9e-e0e64549abdf/quick-roaming-rcoax-with-ipcf-en.mp4

iPCF-MC (2:09 minutes)

https://assets.new.siemens.com/siemens/assets/api/uuid:4bdccad2-362a-41db-b3ef-8c07b884a5db/ipcf-mc-en.mp4

Note on the videos

The videos give a pretty compact overview on the technological basis of the protocols e.g. polling and calculable roaming times.

Typical questions based on the videos are the exact timings for scanning a channel. These expert questions are answered in our Industrial Wireless LAN courses which include a deep-dive into the details of the iFeatures:

https://new.siemens.com/global/en/products/automation/industrial-communication/industrial-network-solutions/education.html

What about co-existence with other WLAN applications?

WLAN itself is a very polite protocol. As soon as a channel is busy (someone else is using/communicating on the channel), WLAN will not transmit its current frame, but wait till the channel is free.

iPCF is behaving as every good WLAN would: waiting for the free channel (so called Tx opportunity) in case the channel is already in use.

As the protocol is relying on being able to poll cyclically on the channel, the existence of other wireless applications on the channel will influence the latency performance.

Therefore, a strict frequency planning has to be done: making best use of the available spectrum and assigning the channels either for general WLAN applications or Industrial WLAN applications.

In short: co-existence of other WLAN applications together with a demanding low-latency automation application which is running on iPCF is done by separating the applications to different channels.

But no worries. As we all know there are quite some channels available (the chart below showing the spectrum in 5GHz, neither showing the available channels in 2,4GHz nor the upcoming 6GHz spectrum):

Best fitting for real-time are the channels without DFS constraints. Very important here: Applications directly involved in the production or the logistics process or the manufacturing process are relevant for availability and the overall output.

This means those applications have to get their needed channels, being higher prioritized than many of the other possible wireless applications, which are ‘just’ there for some visibility and transparency (e.g. human machine interfaces).

What security considerations need to be done?

WLAN itself offers different possibilities to authenticate devices and to encrypt the wireless traffic. From an open system to WPA2/WPA3 in different flavours.

iPCF leverages AES encryption with a preshared key, to make sure that only the right devices are connecting, and to encrypt the wireless traffic.

This means, you have to bring in the key manually to the different end devices before onboarding. The general recommendations for keys in terms of complexity also apply for preshared encryption keys.

Closing

Thanks a lot for staying with me during that blog entry. I hope you found it helpful.

Feel free to share your feedback with me – looking forward to it!