Name: M S Sarang Bharadwaj     Roll No: CS09S022

Automated system for electricity billing and payment 

1  Goal
Design an add­on device for the existing watt­hour meters so that the billing and payment procedure 
can be automated.

2  Why is the idea imaginative and Practical?
The existing cell phone networks were set up to enable people to communicate with each other. The 
proposed idea makes use of this infrastructure to implement a fully automated billing system. Hence 
the   idea   is  creative   and   imaginative.   Since   the   necessary   infrastructure   required   to   realize   the 
proposed idea is already available, it is  practical. Also, the device is an add­on and hence the 
existing watt­hour meters need not be replaced. Thus, the add­on device can be integrated with the 
system that is already in place without much of a problem. 

3  Innovation
The innovative parts of the idea are: 
● The manner in which the watt­hour meter is read and power consumption is recorded 
(explained in section 'The Device') 
● The protocol for remote billing (explained in the section 'Protocols for Remote billing and 
Payment' )
● The device is an add­on and hence can be used with the existing watt­hour meters
● Mobile phone networks used to realise the idea

Since, the device keeps track of electric power consumption it could also display the number of 
units of power consumed by the  user.  This gives the user an idea of the amount power he has 
consumed till date, from the start of the month. This would be an additional feature of the device. 

1
4  Comparison with the state­of­art

At present, most of the houses in India have the traditional mechanical watt­hour meters and the 
billing system is not automated.  At the end of each month a person from the electricity board goes 
to every house and depending upon the meter reading, generates the bill. This is a very naive and 
tedious procedure that can easily be automated with the current technology available. 

There are a few remote billing  systems  which are being used in some parts of the world. The 

mechanism used in these systems are significantly different from the one proposed in this report. 
Currently the following three methods are being used:

• Radio­equipped   handheld   computer   ­    A   meter   reader   carrying   a   handheld   computer 

equipped with a radio receiver walks by homes, without actually entering the premises. The 
devices “radio” (send) their readings to the hand­held computer. The meter reader accepts 
the readings received. The meter reader does not enter the readings manually, eliminating 
any manual entry errors. 
                                                        
• “Drive­by” or mobile data collection ­  This is a very popular method of data collection 
from radio­equipped remote devices. Mobile data collection uses vehicles equipped with 
radio units to read RF module­equipped gas meters via radio, without the need to access the 
meter. A radio transceiver is installed in a utility vehicle. Route information is downloaded 
from the utility billing system and loaded into this radio transceiver. While driving along a 
meter­reading   route,   the   transceiver   broadcasts   a   radio   wake­up   signal   to   all   RF   meter 
modules within range and receives the meter readings when they respond. Completed reads 
are uploaded to the billing system for bill generation. 

•  Fixed network data­collection ­ Several utilities, especially those that read both gas and 
electric meters, are considering deploying a fixed network for remote meter reading. Fixed 
network deployment is usually done as a migration from the mobile data collection system. 
The fixed network is usually installed over areas where advanced metering data, variable 
reads, unscheduled reads or operational improvements are required. 

2
4.1  Problems with the current techniques
The first two techniques mentioned above are automated to a certain extent but not completely. In 
the the first technique the meter reader still has to go from one house to other to collect data. 
Similarly, the second technique requires a person to drive by the houses so that the data can be 
collected.     The   third   technique   requires   setting   up   a   fixed   network   which   increases   the   initial 
investment. 

The proposed idea  is different from the above techniques and it provides a fully automated solution 
for 'electricity billing and payment', that makes use of the existing cellphone networks.
                                 

3
5  A Brief Description of the system

As stated earlier, the system makes use of the cell phone network to automate the billing procedure 
for electricity. This automation is made possible by a device that is capable of communicating over 
the cell phone network. The device is an add­on which is fitted on to the existing watt­hour meters. 
It keeps track of the number of times the aluminium disc within the watt­hour meter rotates. Since 
the   number   of   rotations   of   this   disc   within   the   meter   is   proportional   to   the   amount   of   power 
consumed, the device indirectly monitors power consumption. Tracking the rotations of the disk is 
done with the help of a sensor. Thus, at any point in time the device knows the amount of power 
consumed by the user from the start of the month.
The device regularly contacts the server via the cell phone network and sends the amount of power 
consumed by the user.  The server records the power consumed by the user in a database, which is 
later used to generate the bill. 
At the end of each month, the server using the details in the database, calculates the bill for each 
user and sends a message back to the device. This message contains the amount that the user needs 
to pay for that month. The user can thus check his bill on the device itself. The user can also check 
his bill online at a website that would be maintained by the Electricity Board. SMS Alerts can also 
be used to inform the user about his electricity bill.
The payment procedure makes use of the already existing technologies. The payment can be done 
via a credit/debit card. Apart from this the user can also pay his bill at a nearby office in person 
(caters to those who don't have an Internet connection at home). 

4
6  Technical requirements
The proposed idea has the following technical requirements:
• Cell Phone network for communication between the Device and the Server
• Internet is required if the customer has to pay his bill online via credit card
• Secure transaction protocols like SSL, SET etc. to provide confidentiality to the customers

7  System Architecture

7.1  The Device 

The   following   figure   shows   the   block   diagram   of   the   device.   The   device's   functionality   can 
logically be grouped into the following two parts:
• Sense
• analysis and  response

Transmit data 
using the 
mobile phone 
  Sense  network
rotations

The Device

Watt­Hour Analysis server

    Meter sense and
Response

Fig 1 – Block diagram of the device

Sense ­ This part of the device interacts with the physical world. It is responsible for sensing the 
rotation of the aluminium disk in the watt­hour meter. This can be  done using a sensor.  When the 
sensor senses that one rotation is complete, it sends a signal to the 'Analysis and Response' block to 
take appropriate action.

Analysis and Response ­  This part of the device receives the signal from the sensor. Depending on 
the signal it receives it takes an appropriate action. If it receives a signal indicating that a disc 

5
rotation is complete, the corresponding action would be to increase the number of units of power 
consumed appropriately.
The Device also contacts the server regularly to update the database record corresponding to the 
user. It makes use of the existing cell phone network for this purpose. This interaction is shown 
below.      

  
UPDATE
         
Device Server

ACK

Fig 2 – Device sending 'UPDATE' message to the server

Each time an unit of power is consumed, the device sends an 'UPDATE' message to the server 
asking it to update the database record corresponding to the user. This message contains the unique 
ID (identifies the device), a timestamp and a checksum. The Device then waits for a response from 
the server. The server after receiving the message, updates the database record corresponding to the 
user   and   then   sends   back   an   acknowledgement   i.e.   'ACK'.   If   the   device   doesn't   receive   the 
acknowledgement within the time out  it sends the 'UPDATE' message again. This continues until 
the device receives an 'ACK' message from the server. The interaction diagram for this is as follows

Time out

UPDATE message

ACK message

Device Server
Fig 3 – Interactions occurring during 'UPDATE' message

6
The format of the 'UPDATE' message is shown below

 
ID

Timestamp

Checksum

64 bits
   
    Fig 4 – UPDATE message format

• Timestamp ­  Each 'UPDATE' message sent by the device will contain a timestamp so that 
the device can match the request with the corresponding acknowledgement. This will also 
help   the   server   handle   delayed   and   duplicate   messages.   The   server   keeps   track   of   the 
timestamp of the previously received message. When it receives a message it first checks the 
timestamp to make sure it is not an old message. Only if the timestamp is greater than the 
timestamp of the last message it  updates the database. The timestamp contains the number 
of seconds elapsed since some reference time (Eg. Epoch in UNIX ­ Jan 1, 1970). Since it is 
a 64­bit field it would take a very long time to wrap around.

• ID ­    Each device is associated with a unique ID. It can be a ten digit number like the 
cellphone number of some string of alphanumeric characters. It is used to uniquely identify 
the device and hence the user.

• Checksum ­ This field contains the CRC checksum. This allows the server to determine if 
there were any errors during transmission.

7
7.2  Distributed Architecture
The system uses a distributed architecture which is as shown below.

Main
Server

Server n
Server 1

Server 2

Area 1
Area n

Area 2

Fig 5 – Distributed architecture of the System

In order to ensure that a single server is not overloaded with requests from many devices, the server 
should not be centralised. This can be achieved by having a server in each area within the city and 
this   server   is   responsible  only for the  corresponding area.  This  reduces  the number  of devices 
contacting  the same server and hence reduces the delay. This also makes the system more robust 
and fault tolerant by eliminating a single point of failure. All of these servers are in­turn managed 
by a  Master Server  at the electricity board. It is responsible for coordinating and controlling the 
activities of the Servers in each of the areas within the city.

8
8  Protocols for Remote Billing and Payment

8.1  Remote Billing

To make remote billing possible, the server has to maintain a database which gives the amount of 
power consumed by each user. Since the power consumption is available on a per­user basis the 
electric bill can be prepared using the data for that user.

ID Power Consumption Timestamp Other details

Fig 6 – Various fields in the Database

The database must contain the following fields:
• ID – an unique identifier that uniquely identifies the device and hence the consumer. This 
also serves as the primary key within the database. No two devices can have the same ID.

• Power Consumption – This field gives the number of units of power consumed by the user 
since the beginning of the month. This field is used in the calculation of the electricity bill.

• Timestamp – This field stores the timestamp of the last 'UPDATE' message. It is needed to 
eliminate duplicate 'UPDATE' messages, which can be done as follows. When the server 
receives an 'UPDATE' message from the device it checks the timestamp in the message with 
the timestamp in the database record. It updates the record only if the timestamp in the 
message received is greater than the timestamp present in the database record.

• Other details – Holds other information related to the user like ­ mobile number, address 
etc.

Since the device sends an 'UPDATE' message to the server when an unit of power is consumed,  the 
amount of power consumed by the user is always maintained up­to­date. Thus, at the end of the 
month the server just needs to calculate the electricity bill for each  user and send this info to the 
user. 

9
The user can be informed about the electricity bill via the add­on device, SMS alerts, website etc. 
Each of these methods are explained below.

8.1.1   Device 
In this method the add­on device that is attached to the watt­hour meter itself displays the electricity 
bill to the user. The server sends a 'BILL' message to the device, which contains the amount the user 
has to pay to the Electricity Board. This interaction is shown in figure below.

BILL
Device Server

ACK

Fig 7 – Server sending 'BILL' message to Device

As shown in the above figure, at the end of each month the server calculates the amount a user has 
to pay and sends a 'BILL' message to the corresponding device (identified by the 'ID' field in the 
database).   It   then   waits   for   an   'ACK'   message   from   the   device.   If   it   doesn't   receive   the 
acknowledgement within the timeout it re­sends the message and waits for timeout period again. 
The interaction diagram is shown below.

Time out

ACK message

BILL message

Device Server

Fig 8 – Interactions occurring during the 'BILL' message

10
The format of the 'BILL' message is as shown below.

ID

AMT

Timestamp

Checksum

64 bits

Fig 9 – BILL message format

The various fields are:
 
• ID ­ The unique identifier that identifies the device. This field enables the device to confirm 
that the message was indeed intended for it.

• AMT  – This field contains the amount of money that the user has to pay for the month. 
Since  the  amount  need not  be an integer,  this  field  will be  a floating  point  number.   A 
suitable floating point representation can be used (Eg. Double precision ).

• Timestamp  –   this   field   contains   the   timestamp.   The   device   when   sending   back   the 
acknowledgement will include this timestamp in the 'ACK' message thereby allowing the 
server to  match an 'ACK' message with the corresponding 'BILL' message.

• Checksum – This contains the checksum for the entire message. It enables the receiver to 
determine if there were any errors during transmission.

8.1.2   SMS Alerts
This is another way by which the user can be informed about his electricity bill. The mobile number 
to which the server needs to send the message is stored in the database in the field 'Other details' as 
shown in Figure 6. The server uses this information and at the end of the month sends an SMS to 
the specified number in the database. This message contains the amount that the user needs to pay 

11
for that month. 

8.1.3   Website
This is the third method by which the user can find out his electricity bill. The Electricity Board 
should maintain a Website where the user can log in and check his bill. 

8.2  Payment

The user can pay the electricity bill in many ways. He can pay online using his credit card or pay 
the bill directly at the nearby office authorised for collecting the money from the users.

8.2.1   Payment via Credit Card 

If the user wishes to pay his bill online then he must have access to the Internet. The 'Electricity 
Board' should have a web site where the user can pay his bill. The user navigates to the bill payment 
page where he enters the 'ID' (the unique identifier that is associated with the device) and also 
provides his credit card details. In order to ensure confidentiality the entire session is encrypted and 
it uses a secure transaction protocol like 'SET'. This interaction is shown in the figure below.

Credit Card 
information
Customer Merchant Acquring Bank

Card Association
(Visa, MaterCard ..)

Issuing bank

Fig 10 – Credit Card transaction

The   server   first   authenticates   the   client   using   the   information   he/she   enters.   The   client   also 
authenticates the server to make sure that the server is not actually an intruder posing himself as the 

12
server. Once this two­way authentication is complete the client sends the credit card information to 
the server. The server then sends this information to the 'Acquiring bank'. The Acquiring bank then 
passes on the information to the 'Issuing bank' requesting it to transfer the amount. The information 
exchanges takes place through secure and encrypted channels to ensure confidentiality.

8.2.2  Paying the bill at the nearby office

This is the traditional method for bill payment. Here the customer goes to the nearby office and 
pays his bill in either cash or cheque. The customer then receives a receipt acknowledging his/her 
payment. At present, most of the people are following this method.

There are also many other ways by which the bill could be paid; for example at an ATM. Many 
ATM's allow the customers to recharge their cellphone. Similarly, it can also be used for paying the 
electricity bill. The user just needs to enter the device's unique ID at the ATM machine and it will 
transfer the money from the customer's account to the Electricity Board.

9  Performance

9.1  Bandwidth usage

The amount of bandwidth consumed depends on the number of messages exchanged per second. 
This in turn depends on the rate of power consumption because when a unit of power is consumed 
an 'UPDATE' message is sent. On an average one unit of power is consumed say every  't' minutes. 
Thus an 'UPDATE' is sent every 't' minutes. Since the size of 'UPDATE' message is around 24 bytes 
and the 'ACK' message takes a few bytes, approximately 40 bytes of data is exchanged every 't' 
minutes. 
The Bandwidth used ( B ) can be calculated as follows:
B =  40/(t * 60)   bytes per second
  where,
t = Average time in minutes taken to consume one unit of power
B = Bandwidth consumed

13
9.2  Delay and response time

The   server   is  distributed  and   hence   the   delay   experienced   by   the   device   is   much   less   when 
compared to the situation of having a centralized server. Since, each area within a city will have a 
server, the number of devices talking to a particular server is reduced to only those devices which 
are in the area. This clearly reduces the delay experienced by the devices and improves response 
time.

If the number of devices in an area is 'N', and 'S' is time taken by the server to serve one device, 
then the worst case delay experienced can be calculated as,
D = N * S seconds
where, 
N = number of devices in the area
S = service time in seconds per device
D = delay experienced in seconds

10  Security

Security is required during:
● Exchange of messages 
● Payment

10.1  Exchange of Messages

Cryptographic techniques have be used to ensure that the 'UPDATE' and 'BILL' can't be forged or 
modified (Confidentiality and Integrity). This makes sure that only the device is authorized to send 
such messages and that a malicious entity can't send false 'UPDATE' messages to the server. 
To   provide   Confidentiality   and   Integrity   the   system   uses   the   Public   Key   Infrastructure.   Every 
device has a public­private key pair and also a symmetric key that will be used to encrypt the 
messages. The device  also maintains  the public­key of the server. The server at the Electricity 
Board has a database that contains the public and symmetric keys of all the devices. 
When the device wants to send a message M to the server it computes the hash value H(M) of the 
message and encrypts it using its private key. This encrypted hash values acts as a digital signature 
proving that the message  was indeed generated by the device. This digital signature is then attached 

14
to the message. The message, excluding the Device ID, and the digital signature is encrypted using 
the symmetric key.
The server at the other end after receiving the encrypted message decrypts the message using the 
symmetric key for the device. It then uses the public­key of the device to get the hash value H(M). 
It then calculates the hash value of the received message H(M'). If the computed value and the 
received hash values are the same then the message is accepted.

Message sent by the device:  Es [ M || Ekp [ H(M) ] ]

where,
Es = Encryption using symmetric key
M = Message
Ekp = Encryption using private key
H(M) = hash value of the message M 

10.2  Payment

The system has to provide security when the customer pays his bill online. It should ensure the 
Confidentiality and Integrity of the credit­card information that the user supplies. Various protocols 
are available to achieve this task. One of the most popular one is the SET protocol and this protocol 
can be used to provide security during online payment.

11  Standard Operating Procedure
Every device must be registered with the server.   Each device must regularly contact the server 
sending it the electric power consumption details. The server, at the end of each month, must send a 
message to the device which contains the bill amount. The device displays this bill amount so that 
the user can know his electricity bill for the month.

12  Legal requirements
Since the Device makes use of the existing cell phone network infrastructure, an agreement has to 
be   set   up   between   a  Service   Provider  and   the  Electricity   Board.   The  Service   Provider  must 
guarantee Quality of Service to the system. The resources as such required by the system is not very 
high because it involves the exchange of very short messages and this doesn't take place often. 

15
Hence, the  Service Provider  can easily dedicate some of the resources for the proposed system 
without   much   impact   on   the   the   quality   of   mobile   communication   between   people   who   have 
subscribed to the Service Provider.  

13  Cost of implementation
The cost of implementing the system is not very high. This is because the necessary infrastructure 
for mobile communication is already in place and this forms one of major components of the entire 
system. The only cost that is present is the cost associated with creating the Device, setting up the 
Servers in each of the areas and also the setting up the Main Server.

References

[1]    http://www.toodoc.com/AMR­ppt.html
[2]    http://www.gidnetwork.com/b­7.html

16