m!dge/mg102i - sabur · applicationnotes. m!dge/mg102i. version2.0 5/30/2013 racoms.r .o.mirova1283...

Application notes.

M!DGE/MG102i.

version 2.05/30/2013

www.racom.euRACOM s.r.o. • Mirova 1283 • 592 31 Nove Mesto na Morave • Czech RepublicTel.: +420 565 659 511 • Fax: +420 565 659 512 • E-mail: [email protected]

Table of Contents1. SCADA serial protocols over GPRS routers ................................................................................... 5

1.1. Static Addressing with M!DGE/MG102 router in the centre ................................................. 61.2. Static addressing with a IP gateway to mobile operator centre ......................................... 131.3. Dynamic addressing ........................................................................................................... 141.4. Hybrid GSM/Radio networks .............................................................................................. 23

2. M!DGE / MG102i CENTRE ........................................................................................................... 252.1. A standalone M!DGE in the centre ..................................................................................... 252.2. A leased line to GSM/UMTS network centre ...................................................................... 282.3. Backup of WAN by UMTS/HSPA ........................................................................................ 322.4. Serial port SCADA protocols implementation ..................................................................... 322.5. GPRS and VHF/UHF radio data network combination ....................................................... 34

A. Revision History ............................................................................................................................ 35

3© RACOM s.r.o. – M!DGE/MG102i

1. SCADA serial protocols over GPRS routersHow to handle SCADA applications which use serial interface over a GPRS/EDGE/UMTS mobile net-work, employing M!DGE/MG102 routers.

In recent years, world of communication is ruled by the Internet Protocol stack and RS232(485...) –based interfaces – are generally considered obsolete. Typical SCADA device life cycle is neverthelesslong enough to guarantee demand for good old serial interfaces for several years from now. CommonRS232 to TCP (UDP) converters can help in some cases by creating the required number of transparentpeer-to-peer connections from all remote serial ports to the corresponding (physical or virtual) ports inthe data centre. However such solution requires a special routing arrangement in the centre, hence itis not always feasible. A typical SCADA Front End Processor (the central interface of the applicationto the communication network) uses a proprietary protocol over a single RS232 interface. Eachmessagecoming out from the FEP is addressed and should be delivered to the designated remote serial port.Certainly a transparent broadcasting to all remotes could do the job, making the service provider happy(assuming the resulting bills are paid). Obviously the proper solution is to transmitt the message to thedestination addresss only.

A SCADA serial protocol typically uses simple 8 or 16 bit addressing. The mobile network addressscheme is an IP network, where the range is defined by the service provider (sometimes including in-dividual addresses, even in the case of a private APN). Consequently a mechanism of translationbetween the SCADA and the IP addresses is required. To make things worse, IP addresses may beassigned to GPRS (EDGE, UMTS, etc.) devices dynamically upon each connection.

This application note describes how to efficiently solve this problem using RACOM made routers.

Three basic situations are described:

a. The mobile network uses static IP addressing and the interfacing device to the SCADA centre isa GPRS router. Such scenario is suitable for small networks with tens of remote stations.

b. The mobile network uses static IP addressing and the SCADA centre is connected to the networkthrough a special IP gateway. This model can be used for networks with tens to hundreds remotes.

c. The mobile network uses dynamic addressing for remote locations and a static address in thecentre. Typically an IP gateway to mobile network is used in the centre and VPN tunnelling isemployed. This design can be used for network of any size and it should be always used for largenetworks with hundreds or more remotes.

All three scenarios require a special device in the centre to do the address translation for outgoingmessages (the SCADA protocol address to the IP address/port pair). RACOM RipEX radio modem isused in the following examples, as it is the straighforward and most economical choice for the task.Moreover it opens the possibility to combine GPRS and private radios in one SCADA network (seeSection 1.4, “Hybrid GSM/Radio networks”).


SCADA serial protocols over GPRS routers

1.1. Static Addressing with M!DGE/MG102 router in the centre

Fig. 1.1: Typical layout of a GSM/UMTS network with static addresses

1.1.1. Setting the RipEX (address translating router)

The RipEX router in the centre wraps the complete incoming RS232 message into a UDP datagram,while reading the destination SCADA address and determining the respective IP address/UDP portpair.

The minimal required setting for this task is as follows:

M!DGE/MG102i – © RACOM s.r.o.6


Menu Settings

The following values have to be changed from the factory settings (the red framed fields in the pictureabove):

• The IP address and Mask of the Ethernet interface of RipEX - the address has to be in the sameLAN with the connected M!DGE/MG102 router.

• COM 1 (or COM 2) interface. The setting of Baud rate, Data bits, Parity and Stop bits has to matchthe setting of the SCADA centre.

• Protocol at the respective COM has to be set according to the SCADA protocol used. Many SCADAprotocols can be handled by the universal "UNI" protocol (see the Application Note UNI protocol).

Setting of Protocol parameters

The following is a typical example where the Modbus serial protocol is used:



Master mode of the protocol has to be always used in the centre. In a small network, a table will betypically used for translation between protocol and IP addresses. Fill in the Dec (or Hex) format of allSCADA addresses (one per line) and the corresponding IP addresses (static IP addresses of SIM cardsused at the respective remote M!DGE/MG102s). Each UDP port has to be the same as the Local UDPport set at the COM server at the respective remote M!DGE/MG102 router.

Menu Routing

The Gateway for the IP address range of all remote M!DGE/MG102s has to be set to the IP addressof the central M!DGE/MG102 (and it has to fall within the range assigned to the ETH Interface).



1.1.2. Setting of the central M!DGE/MG102 router

Seting of NAPT

All incoming UDP datagrams from the mobile network (originated at the remote M!DGE/MG102s) haveto be sent to the IP address of RipEX router in the centre, to the UDP port number corresponding withthe serial port where the SCADA centre is connected – it normally is 8881 for COM 1 or 8882 for COM 2.The External port range has to contain all remote UDP ports set in the respective COM servers of remoteM!DGE/MG102s.

Setting of routing

The Default GW (Destination 0.0.0.0, Netmask 0.0.0.0 and Gateway 0.0.0.0) has to be assigned to theMobile Interface.



1.1.3. Setting of remote M!DGE/MG102 routers

Setting of COM port

The setting of the Serial port has to match the respective RTU serial port setting.



Setting of the COM server

The UDP raw protocol on the IP port shall be used.

The Local UDP port has to correspond with the respective port number set in the address translationtable in the central RipEX (see the section called “Seting of NAPT”.). The mobile interface IP addressof the central M!DGE/MG102 shall be filled in the Remote IP field, the Remote Port shall be 8881 whenCOM 1 is used at the central RipEX, 8882 when it is COM 2.



Setting of routing

The Default GW (Destination 0.0.0.0, Netmask 0.0.0.0 and Gateway 0.0.0.0) has to be assigned to theMOBILE1 Interface.



1.2. Static addressing with a IP gateway to mobile operator centre

Fig. 1.2: Typical layout with IP gateway to a mobile operator centre

1.2.1. Setting the RipEX (address translating router)

The setting of the central RipEX is the same as described in the Section 1.1.1, “Setting the RipEX(address translating router)” chapter above. The only difference comes in the Routing menu, wherethe IP gateway address has to be set as the gateway for the IP address range of all remoteM!DGE/MG102s, instead of the central MG102/M!DGE router address (there is no such central GPRSrouter in this layout). See Section 1.1.1, “Setting the RipEX (address translating router)” for details.

1.2.2. Requirements on the IP gateway provided by the mobile operator

Some settings have to be done by the mobile operator. The necessary minimum has to meet the fol-lowing two requirements:

• all UDP datagrams outgoing from the RipEX IP address have to be delivered to the IP addressesand the respective UDP ports of remote M!DGE/MG102 routers

• all UDP datagrams from the remoteM!DGE/MG102 addresses have to be delivered to the IP addressof the RipEX in the centre (with UDP ports 8881 or 8882)

1.2.3. Settings required for Remote M!DGE/MG102 routers

The settings are the same as described in the chapter Section 1.1.3, “Setting of remote M!DGE/MG102routers”. The only difference is in the Remote IP field in the COM server setting (see Section 1.3.2,“Setting the Ripex (address translating router)”.), where the IP address of the central RipEX shall befilled in.



1.3. Dynamic addressing

When the IP addresses are assigned to remote M!DGE/MG102 routers dynamically, the simple staticrouting can not be used. Whenever a remote router establishes the connection to the GSM network,it receives a new IP address. In order to faciliate two way communication between remote and centralserial ports, the M!DGE/MG102 routers support two standard types of VPN tunnels (http://en.wikipe-dia.org/wiki/Virtual_private_network) - IPsec (http://en.wikipedia.org/wiki/IPsec) and OpenVPN (ht-tp://en.wikipedia.org/wiki/OpenVPN). Upon every connection to the network, a remote router createsa tunnel to the VPN concentrator in the centre (remeber a static IP address in the centre is always re-quired). Every time a tunnel is established, the routes to IP addresses/networks connected through itare added to the routing tables in the centre. The additional advantage of VPN tunnels is higher securityof data transfered through the public network.

The VPN concetrator in small networks with several remotes can run in the central GSM/UMTS router(with static IP address assigned), in large networks a specialized IP router (e.g. Cisco) is needed anda leased line connection to the operator's gateway is used (similarly to the arrangement described inthe paragraph Section 1.2, “Static addressing with a IP gateway to mobile operator centre” above).

Fig. 1.3: Typical layout of a GSM/UMTS network with VPN tunnels

1.3.1. VPN concentrator

IP Sec

IPsec can be used in a network of any size. A dedicated router (or several routers) serve(s) as the VPNconcentrator. The choice of vendor and type depends on the SLA requirements and the size of thenetwork - RACOM has positive experience with Cisco routers (IOS or ASA based), however routersfrom other vendors (e.g. Juniper, Netgear, WatchGuard or others) can certainly be used.



The following routers were used as IPsec VPN concentrators:

• M!DGE - up to 4 tunnels

• Cisco 871-K9 up to 10 tunnels

• Cisco 1841-HSEC/ K9 up to 800 tunnels

Please follow the instruction in the user manual of the specific router for IPsec tunnel settings. RACOMsupport team can assist you with basic settings for Cisco routers.

OpenVPN

Since OpenVPN is based on universal network protocols (TCP and UDP), it is desirable alternative toIPsec when the operator's firewall blocks specific VPN protocols. OpenVPN works in multiclient-serverarrangement – a short description of configuration of an OpenVPN tunnel with M!DGE follows.

OpenVPN Server in M!DGE

A M!DGE router can act as a VPN server for networks with up to 10 OpenVPN tunnel connections; forlarger networks a Linux or Windows based server should be used.

Fig. 1.4: Typical layout of a small network

The first step is enabling OpenVPN administration:



Setting the Server of Tunnel 1:



Default values can be used. When root and server certicates are missing they have to be generatedin the Key & Certificate window; Manage keys and certificates link shall be used as a short cut.

Use the Create button to generate the server certificates and keys.

After successful generation you can check the certificates using the View link. You can also continuewith setting of the OpenVPN using Configure link. The available clients for the server are displayed atthe bottom of the window.



In the Client Management window you can prepare configuration, certificates and keys for several clients.



Expert mode files can be downloaded for all clients:

The OpenVPN Client in M!DGE.

The next step is setting the clients. First you need to set all the standard settings of Eth (IP address,mask) and mobile connection.



Configuring an OpenVPN client is strightforward. Enable the Open VPN first:

Then you can use expert mode of OpenVPN configuration – upload the respective file generated bythe server:

Alternatively you can proceed step by step using standard settings. Make sure that the respectivesettings of Server and Client match.



You can manualy upload client keys and certificates generated by server.



Finally you have to set the route to the central LAN to the respective interface (e.g. TUN1 as in ourexample):

Important

Time synchronisation of server and all clients is required - without the time synchronisationthe OpenVPN tunnel can not be established. You can use the central M!DGE as an NTP



server - before establishing of tunnel only the static IP address of the central M!DGE isreachable. When there is a time server available within the GSM/GPRS network, it can bealternatively used.

When the server and all clients are configured, the OpenVPN tunnels are ready.

1.3.2. Setting the Ripex (address translating router)

Setting of the central follows the same steps as described in the chapter Section 1.1.1, “Setting theRipEX (address translating router)”. The destination IP addresses in the translation table have to bethe Eth interface addresses of the respective remote M!DGE/MG102 routers.

1.3.3. Setting a remote M!DGE/MG102 router

Besides setting of the OpenVPN tunnel, the RS232 and COM server parameters have to be properlyconfigured. The tunnel interface is the route to the central application. Please follow the instructions inchapters Section 1.1.2, “Setting of the central M!DGE/MG102 router” and Section 1.1.3, “Setting ofremote M!DGE/MG102 routers”.

1.4. Hybrid GSM/Radio networks

The RipEX in the position of the address translation centre can be simultaneously used as the centralradio modem in a standard UHF/VHF network.



Router mode should be used. All SCADA protocol addresses are translated to the respective IP ad-dress/UDP port pairs and the IP routing table in the RipEX decides whether the UDP datagram entersthe GSM or UHF/VHF radio network. Please check the RipEX manual for detailed information on theconfiguration.



2. M!DGE / MG102i CENTREThis document is intended to be a support material for RACOM sales department. A detailed ApplicationNote shall be written to provide assistance with a concrete technical solution; do not hesitate to askRACOM TS for help with a specific solution of a project :-)

Please note that while terms “SCADA CENTRE” and “RTU” are used in following pictures, the arrange-ments described apply to any application devices (like ATMs, lottery terminals, surveillance cameras,...)with the same type of interface (Eth or serial). Since the serial connection is discussed in the applicationnote “SCADA serial protocols over GPRS routers M!DGE/MG102” (see http://www.ra-com.eu/eng/products/m/midge/app/index.html), we concentrate on Eth-based applications in this doc-ument.

2.1. A standalone M!DGE in the centre

This simple and easy solution is feasible for small networks with up to about 20 M!DGEs. Note that thecentre reliability in this arrangement is limited by the reliability of the GPRS/UMTS service in the centrallocation.

2.1.1. Central M!DGE – static addresses

Static IP addresses are required for all SIM cards.


M!DGE / MG102i CENTRE

2.1.2. Central M!DGE – VPN tunnels

Static IP address is necessary for Central SIM card only - all others may use dynamic IP addresses.

VPN Tunnels have to be initialised from remotes to the centre. The Midge in the centre is capable tosimultaneously handle maximum 10 OpenVPN tunnels and 4 IPsec tunnels. I.e. max. 10 remotes forone application and another 4 for the 2nd application.

When a higher number of tunnels (i.e. a higher number of remote units) are required, a VPN concen-trator has to be added - a special router (e.g. CISCO) for IPsec tunnels, an ordinary PC (Linux orWindows) for OpenVPN tunnels.



2.1.3. Redundant M!DGE in centre – VPN tunnels only

Two M!DGEs with virtual router protocol (VRRP) can be used. The VRRP (one virtual IP) is active forlocal LAN, Two independent static SIM IPs (one for each Midge) are used for GPRS network. OpenVPN(not the IPsec) is recommended for this scenario.



This solution increases the reliability of centre in terms of HW. A redundant VPN concentrator (cluster)solution may be used to further improve the reliability. However a leased line to the GSM operatorcentre is more reliable solution and it is recommended whenever the reliability of the network reallymatters. (see Section 2.2, “A leased line to GSM/UMTS network centre”)

2.2. A leased line to GSM/UMTS network centre

This scenario is feasible for networks with any number of remote sites. A leased line normally providesa better reliability than a wireless GPRS/UMTS connection and its capacity is not limited by the GSMtechnology available at the centre location. The leased line connects the SCADA centre directly to theoperator's COREWAN. Sometimes it can be substituted by an Internet connection between the SCADAcentre and the operator's centre.

2.2.1. Leased line connection – static addresses

Static IP addresses for all SIM cards are required.



2.2.2. Leased line connection – VPN tunnels

The static IP address in the centre is used, the SIM cards in remote M!DGEsmay have static or dynamicIP addresses.

A VPN concentrator has to be used - a special router (e.g. CISCO) for IPsec tunnels, an ordinary PC(Linux or Windows) for OpenVPN tunnels.

The redundant VPN concentrator (cluster) solution may be used for higher reliability.

2.2.3. Redundant connection of remotes using two different GSM providers

Dual SIM MG102i – When the primary provider network fails, traffic is automatically switched to thesecond provider.

Even with a single provider, two independent Access Point Names can be used to improve overall re-liability.



The fully redundant solution of the centre is possible as follows:

Remote redundancy with two M!DGEs with VRRP - this solution can handle both the network servicefailure and the M!DGE router (+ antenna installation) HW fault(s).



A fully redundant solution for both the centre and remote locations is certainly possible.



2.3. Backup of WAN by UMTS/HSPA

Under normal circumstances, VPN tunnels between remote and central M!DGEs are established overtheWAN network. When theWAN fails, the traffic from/to the respective remote M!DGE is automaticallyredirected to the mobile network.

2.4. Serial port SCADA protocols implementation

2.4.1. Point to multipoint communication

SCADA protocols on serial interface use proprietary addressing. Since IP addresses have to be usedin the GPRS network, a translation between the SCADA addresses on serial port and IP addresses isrequired. Additional equipment (e.g. a RipEX) is therefore needed in the centre.

The RipEX in the centre wraps serial data into UDP datagrams and sends them to the respective IPdestination addresses according to the rules set for the SCADA to IP address translation. The remoteM!DGEs receive these datagrams, unwrap the serial data and send it to their respective serial interfaces.

Remote units use the “Com server” and send all data from serial interface, wrapped in UDP datagrams,to the central static IP address (VPN tunnels can be used). The central RipEX receives these datagrams,unwraps the serial data and sends it to the SCADA centre.

Note that the arrangements described in Section 2.1, “A standalone M!DGE in the centre” and Sec-tion 2.2, “A leased line to GSM/UMTS network centre” apply also to the serial SCADA protocols.



For detail information se Section 1.1, “Static Addressing with M!DGE/MG102 router in the centre”.

2.4.2. Point to point communication

When a simple point-to-point link between two serial port SCADA devices is needed, no extra equipment(RipEX) is necessary. M!DGE routers at both ends of the link use the same configuration as the remoteones in point-to-multipoint scenario above. The Com servers are used for serial data to UDP datagramconversion. At least one of the M!DGEs has to have a static IP address, while the other can have adynamically assigned one - a VPN tunnel has to be used then Section 2.1.2, “Central M!DGE – VPNtunnels”.



2.5. GPRS and VHF/UHF radio data network combination

The picture above describes an arrangement, where part of the remote sites is connected over a privateUHF/VHF radio network (e.g. sites requiring 99.9% availability) and the remaining sites are connectedover a GPRS public network (e.g. distant, isolated locations where it would be uneconomical to extendthe radio coverage to). The M!DGE part functionality and settings are the same as described in theSection 2.4.1, “Point to multipoint communication”. Then the RipEX serving as the master of the radiopart interfaces the SCADA centre, performs the serial data conversion (when needed) and then decideswhether a UDP datagram enters the GSM or the UHF/VHF radio network. Please check the RipEXmanual for detailed information about the radio network settings.



Appendix A. Revision History2011-12-15Revision 1.0

First issue

2013-05-21Revision 2.0Added second chapter


Revision History

m!dge/mg102i - sabur · applicationnotes. m!dge/mg102i. version2.0 5/30/2013 racoms.r .o.mirova1283...

Documents