040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 40

A UK ELECTRICITY DISTRIBUTION NETWORK OPERATOR (DNO) BROUGHTTOGETHER A TEAM OF EXTERNAL CONSULTANTS, INTERNAL IT RESOURCE,

EQUIPMENT SUPPLIERS, AND A MOBILE PHONE OPERATOR TO DELIVER ANOPERATIONAL GPRS (GENERAL PACKET RADIO SERVICES) BASED TELECONTROL

INFRASTRUCTURE CAPABLE OF SUPPORTING OVER A THOUSAND REMOTELYCONTROLLED SWITCHES IN THE DNO’S 11KV DISTRIBUTION NETWORK.

by Andrew J. Wilson

The use ofGPRStechnology

for electricity network telecontrol

40

ww

w.ie

e.or

g/co

ntro

l

There were a number of key technicalchallenges to be overcome right at the start of this undertaking, not least the fact that no one had before undertaken such aproject of this scale and type using GPRS.

The most significant challenges, identified by the teamup front, included:� Change in operating protocol – Moving away from a

‘scanning’ protocol to a ‘Report By Exception (RBE)’protocol;

� IP addressing – dynamic versus static addressing; and � GPRS Session Management.

OPERATING PROTOCOLThe operating protocol in use with the existing NetworkManagement System (NMS) was designed for use with fixedlinks or scanning radio telemetry. This type of protocol ishighly inefficient when applied to an IP environment. IPnetworks perform at their best when traffic is of anirregular “bursty” nature; also, shared infrastructure accessservices, such as GPRS, are charged for on a per unit basis.

IEE Computing & Control Engineering | April/May 2005

The combination of these two factors meant that for anew IP based infrastructure to operate effectively the DNOwould need to change their operating protocol away from acyclically scanned protocol to one that operated on a RBEbasis, i.e. data would only be transmitted as required, wheneither a change in state occurred or a control action wascarried out.

IP ADDRESSINGGPRS is inherently a “mobile” technology and theallocation of addresses is managed dynamically by thenetwork operator concerned; however, for a remote controlapplication the host system must always know the addressof the remote device in order to issue a control command.

A GPRS terminal is normally assigned a relativelyrandom address from the operator’s pool of IP addresseswhen the terminal establishes a context (see the VPNsection in Design). This method of assignment is notappropriate for remote control applications.

The project team worked with the operator to utilise afeature within the authentication process, which allowedthe IP address to be chosen from a set range by the client’s

040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 41

GPRS for control

system. This, while still technically a dynamic addressingprocess, provided the host system with one of two addresseswith which to access the device.

SESSION MANAGEMENTBecause of the mobile nature of most GPRS terminals, themanagement of the session is controlled from the remoteterminal; this means that all communication (PDP Contextsessions) must be set up and managed from the field end.

This presents a problem for this type of application as aremote device must always be present to respond to apotential control from the host system but the host systemis not able to initiate a session. This was overcome bybuilding intelligence into the remote terminal so that it

monitored the session remotely and re-established if therewas any issue, thus ensuring it was always available torespond to communication from the host.

THE ISSUES: PROJECT SPECIFICIssues and risks to the project had to be identified andresolved quickly so as not to hinder the progress of such a“pathfinder” project. These issues were found to fall intoone of two broad categories: project specific and technical.

In order to maximise the returns from this project theroll out had to be started early following fast-track designand procurement phases. This meant the design andsolutions were still evolving during the first phase of roll-out. To counteract the potential for substantial down ➔

IEE Computing & Control Engineering | April/May 2005 41

42 IEE

ww

w.ie

e.or

g/co

ntro

l

040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 42

time resulting from system upgrades a flexible over-the-airconfiguration facility was built into the first release of theRTUs.

This project required the addition of new RTUs andfunctionality to the existing legacy NMS. Prior to thisproject the NMS only communicated using the legacyscanning protocol Ferranti Mk3. Support for additionalprotocols would be required; in this case the open protocolDNP3 was chosen to meet the need for an RBE basedprotocol.

Cost, as always, was an issue for this project. In this casehowever a balance had to be drawn between the limitedreturns available from improving performance metricssuch as CMLs (Customer Minutes Lost, an importantelectricity industry KPI) and the operational costs ofrunning the telecommunications infrastructure supportingany solution put in place. In this case by using a sharedpublic service such as GPRS and making use of existing ITinfrastructure, the operational cost for 1,000 RTUs hasproved to be less than £75,000 per annum; considerably lessthan alternatives such as scanning radio or public packetradio services.

THE ISSUES: TECHNICALThe DNP3 protocol has become the de-facto standard forRBE applications within the electricity industry; however,while the existing NMS provider had experience ofimplementing DNP3 over TPC/IP on fixed networks thiswas their first experience of carrying the protocol over awireless infrastructure. There was, therefore, considerablework involved in optimising the NMS DNP3 driver for useover GPRS.

Open protocols, such as DNP3, are inherently open to acertain level of interpretation and contain many features,not all of which are implemented within every driverdeveloped. In order to avoid mismatches between driverswithin the RTUs and that installed on the host NMS, thedevice profile for each driver had to be analysed to ensurethat the features used within the application in questionwere comparable, and steps taken to correct the situationwhere they were not.

THE DESIGNThe key theme throughout the design phase of this projectwas to create a solution which met the needs of the projectand could be rapidly implemented, while remaining flexibleto incorporate inevitable changes.

We will not attempt to describe in detail all aspects of thesolution design, only those key areas which will be ofconcern to parties involved in similar projects. These keyelements to the design are mobile network VPN, networksecurity, network authentication, addressing, RTUs, andSCADA.

Computing & Control Engineering | April/May 2005

The key theme throughout thedesign phase was to create asolution which met the needs ofthe project and could be rapidlyimplemented

‘‘’’MOBILE NETWORK VPN

In order to create connectivity between two or more devicesconnected to a GPRS network the devices must first attachto a VPN within that network. Most GPRS networks operatetwo forms of VPN:� Public VPN – Shared open VPN to which any registered

terminal can gain access (with or without Internetaccess); and

� Private VPN – Secure VPN dedicated to particularservice or customer.In order to provide greater levels of security the project

chose to set up a dedicated Private VPN within their chosenoperator’s network. The mobile operator allocated a fixedrange of IP addresses to this VPN and issued SIMs pre-registered to access the VPN. The mobile VPN terminatesat two sites where it is connected to the public side of theDNO’s Internet firewalls.

NETWORK AUTHENTICATION / SECURITYSecurity of access to the Tele-control network is providedat two main levels:� Mobile network SIM registration; and� Mobile VPN authentication.

Each SIM supplied to this project comes pre-registeredon the Tele-control VPN by the operator. Only SIMsregistered in this way by the operator can access the VPN,thus preventing access, accidental or otherwise, by otherparties.

When a remote terminal attempts to establish a contextsession with the VPN it must submit details of itsidentification for authentication purposes. Each terminalholds a unique “username” and “password”, which areunknown to the mobile operator. When the mobile networkreceives a request to establish a connection, the networkpasses the “username” and “password” onto the DNO whothen compares the identification details with a userdatabase before instructing the mobile network to accept orreject the request from the remote terminal.

ADDRESSINGThe RTUs are addressed at two separate layers within thenetwork:� Application Layer – DNP Address; and� Network Layer – IP Address.

GPRS for control

040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 43

AuthenticationServer

DataGatherer

DataGatherer

Firewall

FirewallInter-site

router

MobileNetwork

End-pointRouter

MobileNetwork

End-pointRouter

GPRSGateway(GGSN)

GPRSGateway(GGSN)

MobileOperatorPacket

BackboneNetwork

RTUOutstation

RTUOutstation

CellBase Station

CellBase Station

High-level network diagram detailing keyelements of mobile wireless, mobile backboneand corporate (enterprise) networks.

’’

The DNP and IP addresses are held in the NMS SCADAapplication against each RTU symbol. Every symbol is tiedto a unique DNP address but the system is free to select oneof two IP addresses. The two IP addresses relate to the rangeof IP addresses allocated by the mobile operator for the twoVPN end-point routers, and are configured in such a way toprovide resilience of connection to the VPN.

The IP address assigned to the terminal, onestablishment of a context session, is determined by themobile network; however in this case, in order for theaddress allocation to appear static, the mobile networkassigns an address from a set range and is determined aspart of the authentication process.

RTUsThe project deployed two different makes of remote switch.In order to reduce delivery risk, each switch was then tiedto a different GPRS interface solution, again to reduce thedelivery risk to the project.

While each interface solution had the same goal, i.e. tofacilitate communication over GPRS between remoteterminal and host, the two adopt very different approachesto this:

RTU A – The interface acts as a ‘dumb’ terminal serverand ‘wraps’ up any serial data received in TCP and sendson to the host

IP network technologies are wellunderstood by internal IT teamsand specialist SCADA knowledge isless essential

‘‘

RTU B – The interface acts as a DNP master/slave RTUin its own right; the interface receives information from theRTU, and maps it into a database before sending it on to thehost.

The RTUs were to be installed high on the electricitypoles in order to reduce the safety risk to livestock andpersonnel. This identified an operational issue formaintenance engineers carrying out fault finding andupgrade activities; they would not be able to access theequipment without first de-tapping the electricityconnection to the RTU (a four man task).

In order to overcome this problem two strategies wereadopted. First it was decided to provide a second serial porton the IP interface within the RTU to allow “over the ➔

IEE Computing & Control Engineering | April/May 2005 43

44

ww

w.ie

e.or

g/co

ntro

l

040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 44

THE CHOICE OF GPRSHaving assessed the relevant suitability of the technology optionspresented, the decision was made by the Electricity DistributionNetwork Operator to adopt GPRS as the bearer technology forsecondary telecontrol devices. This decision was made basedupon the low capital cost of field based communicationsequipment (£200 per RTU), the low operational data costs (2pence per day predicted), and support for IP basedcommunications, which is in line with the long-termcommunications strategy.

THE TECHNOLOGYGeneral Packet Radio Service (GPRS) is an Internet Protocol (IP)based data-only infrastructure overlaid on GSM. GPRS makes useof the GSM air interface by using the same control and trafficchannels. However, GPRS data are separated from GSM callswithin the core network and is routed over dedicatedinfrastructure.

GPRS can utilise multiple time slots within a GSM frame andhence data rates of up to around 50kbps are supported. GPRSand GSM share the physical channels available within a GPRSsupported mobile phone cell. The cell can therefore choose todynamically allocate additional channels to GPRS if GSM trafficis low. Most operators will reserve at least one channel to act asa dedicated GPRS channel.

GPRS operates as a shared data service; a mobile terminalonly occupies a channel when it is actually sending or receivingdata packets. In between times the channel is released for otherterminals to use. This means that a mobile terminal shouldalways be able to gain access to a data channel regardless of theamount of concurrent open voice calls (one or more channelsreserved for GPRS) and will always be able to send and receivedata albeit at a reduced data rate depending upon the level ofcontention.

Third Generation (3G) data services are delivered over anentirely separate network from GPRS. This separation of networksmeans that 3G is not likely to replace GPRS directly, as voicerequirements will ensure that GSM networks remain in place forsome considerable time with GPRS remaining in co-existence.

GPRS OPERATORS MARKETWithin the UK, all the GSM network providers offer GPRSservices: mmO2, Orange, T-Mobile, and Vodafone.

GPRS is used as a bearer technology for other services, suchas picture messaging, and as a result the majority, if not all, ofeach operators’ cells will be GPRS enabled. The commercial offer,in relation to GPRS, varies from operator to operator; however,typical large-scale agreements are likely to attract line rentals ofless than £5 per month and usage charges of £1 per megabyteor less.

IEE Computing & Control Engineering | April/May 2005

air” diagnostics and re-configuration. Secondly, a Bluetoothmodule was installed to a local diagnostics port on the RTUto provide short-range wireless connectivity.

SCADAThe SCADA system had to be enhanced to support DNP3communications. This was done through the addition oftwo new front-end communications processors eachrunning a newly developed DNP3 communications driver.The front-end processors were configured in such a waythat they could share the communications load undernormal operation but could each handle the full load if theother should fail.

THE OUTCOMESThe implementation of this scheme by the DNO has seenmany benefits gained for the business; however, in terms ofthe communications infrastructure elements of the projectthere are several areas which the project team consider tobe of particular importance:� Low cost – An operational cost, for 1000 RTUs, of less

than £75,000 per annum;� Quick to implement – Pre-configuration and testing

carried out in the workshop led to shortened on-sitecommissioning phase;

� Open standards – DNP3 is a non-manufacturer specificprotocol allowing multi-sourcing of RTU / SCADAequipment/software; and

� Non-specialist support – IP network technologies are wellunderstood by internal IT teams and specialist SCADAknowledge is less essential.

LESSONS LEARNEDAs with any project there are certain aspects which exceedor fall short of expectations. We would like to present someof the key lessons that we learned. Anyone contemplatinga similar project would be well advised to take note of thefollowing items.

Signal survey – Desktop coverage surveys by the mobileoperator are all well and good but cannot replace real on-site surveys. Complete RF site surveys are, however, timeconsuming and expensive. This project utilised on-phoneengineering software to assess the signal level and cell IDat each site. If the signal fell below an agreed confidencelevel then alternative locations were sought. This processvirtually eliminated the number of “no signal” sites andtotally eliminated the risk of sites being installed, only forlow signal to become an issue at commissioning. The surveyalso identified the cell ID. This allowed the team to allocatean antenna position giving the best chance of strongreception.

Proof-of-Concept – The project developed a basic Proof-of-Concept (PoC) trial, which tested the principles behind the

XxxxXxxxxxXxXxxxxxxx

040-045_CCE_AprMay05_EN 8/4/05 11:39 am Page 45

EnterpriseFirewall(s)

BluetoothInterface

GSM/GPRSModem

Gas Switch Actuator

RTU

RTU

Control

Config

TerminalServer

COM 0COM 1COM 2COM 3

Interface

GSM/GPRSModem

Mobile PhoneGPRS

Network

Mobile VPNEnd-point

Router

EnterpriseInternalNetwork

SCADA

RadiusServer

Block Diagram showing interconnectivitybetween SCADA application and remoteactuators

Open protocols have theiradvantages, but the choice offunctions and features is wideand varied. Careful planning isa must.

‘‘’’

design at a very early stage. The results of this PoC werethen used to fully define the design and allow the suppliersinvolved to further develop their offerings ahead of theformal procurement phase. This had the overall effect ofsignificantly shortening the design phase as well asreducing the risk to the delivery of the project as a whole.

Open protocols – While open protocols undoubtedly havetheir advantages, the biggest drawback is that the choiceof features and functions available within the protocol iswide and varied, and each implementer of the protocol isfree to choose which aspects of the protocol to includewithin their driver software. Careful analysis must,

therefore, be made to ensure that the device profile of eachprotocol driver, used with the system as a whole, is fullycompatible.

Pre-commissioning – The national coverage provided byGPRS coupled to its cellular architecture means that oncea device has been proven in one location it should continueto work regardless of location, provided sufficient signal ispresent. This meant that all RTUs could be fully configuredand tested back to the host SCADA system in a workshopenvironment, allowing for a “plug-and-play” type process tobe adopted for the field commissioning phase.

Optimisation of protocols for Wireless IP – The underlyingtransport mechanism behind IP and the specificimplementation of DNP3 over IP used by the project wereintended to be used over fixed communications links. Theuse of wireless technologies, such as GPRS, to carry theseprotocols highlighted a number of issues with regard totiming, error correction, and re-tries, all of which requireda degree of optimisation before communication could beregarded as stable and reliable. �

The author, Andrew J. Wilson, is a senior consultant forMason Communications Ltd (www.mason.biz) and may bereached at andrew.wilson@mason.biz

IEE Computing & Control Engineering | April/May 2005 45