Facility Networking with IP over RS485:
Packet Control for Master-Slave Cascaded Networks
Hideya Ochiai
Hiroki Nakagami
Yuuichi Teranishi
Hiroshi Esaki
The University of Tokyo / NICT The University of Tokyo NICT / Osaka University The University of Tokyo
jo2lxq@hongo.wide.ad.jp
nkgami@hongo.wide.ad.jp teranisi@cmc.osaka-u.ac.jp
hiroshi@wide.ad.jp
Abstract—In Smart Grid applications, we need to access end
devices for monitoring and control over varieties of communication media (e.g., wireless, wired and power-line communications).
The Internet Protocol is useful because it can integrate thoseheterogeneous media by IP over X architecture. In this paper, we
focus on the integration of RS485, an optimal communication
media for facility networking in buildings, proposing IP over
RS485. We introduce a dynamic priority-based packet-control
scheduler (DPPCS) with master-slave and token-passing, andcontrol the transmissions of IP packets on RS485. According
to our evaluation with a 20-node and 200-meter scale RS485
testbed, IP over RS485 can perform well for many facility
networking applications. It shared the bandwidth among active
IP communication nodes. The buffering duration for non-active
nodes to transmit the first IP packet were moderate. It had great
tolerance for simultaneous packet transmissions.
Keywords—Building Automation, IP, RS485, Facility Networking

I.

I NTRODUCTION

Smart Grid requires a facility administrator to monitor
power usage and to control HVAC (heating, ventilation andair-conditioning), lights, power outlets, and other facilities
in buildings in near real-time. We are now trying to use
the Internet Protocol (IP) to achieve this goal[7], [16]. IP is
considered to be useful for providing basic connectivity to theinterfaces of monitoring and control devices over heterogeneous communication media. For example, 6LoWPAN[13] hasenabled to provide IP connectivity to such end devices overIEEE802.15.4 wireless links. However, legacy wired-networks
especially used for monitoring and control applications still do
not have IP-layer over it.
RS485 is one of the legacy communication media, whichallows low-cost and reliable deployment of facility networks.
It is commonly used in buildings worldwide almost as a defacto standard. However, the implementation of IP-layer over
RS485 is still not common, or even not sufficiently studied
according to our survey.
This paper proposes the architecture of IP over RS485,
which enables IP-based facility networking over the wellmatured, low-cost and reliable communication media for buildings. We take master-slave and token-passing (MS/TP) scheme
to control the delivery of IP packets over RS485. We introduce
a dynamic priority-based packet-control scheduler (DPPCS)
to optimize IP-based communication on RS485, and study
the performance regarding to (1) packet buffering duration,(2) throughput and (3) tolerance for simultaneous packet
transmissions.

Fig. 1. RS485 is one of the most optimal communication media for facility
networking. If we use Ehernet, we have to deploy switching hubs and many
UTP cables.

RS485 is a half-duplex, low-speed and multipoint serial
communication media. It connects multiple nodes in cascadedmanner usually on a single twisted-pair cable. It makes serial
communication with differential signaling over 1km. The typical link speed for RS485-based networking is between 9.6kbps
and 115.2kbps.
RS485 allows low-cost installation compared to the switchbased Ethernet (i.e., 10Base-T and above). It allows the installation with only a single cascaded cable from the masternode to the monitoring and controlling devices (i.e., slaves).
However, if we use Ethernet, we have to deploy UTP cablesfrom the switching hubs to the devices one-by-one over theceilings or behind the walls.
Typically, RS485 comes with an application protocol suchas Modbus[12], BACnet[6] and Profibus[2]. They commonly
take MS/TP schemes for delivering their application messages.
We also take this approach for delivering IP packets over
RS485. MS/TP avoids data-frame contention and provides thecapability of traffic control, which is suitable for such a halfduplex and low-speed media.
DPPCS, which we introduce in this paper, schedules tokens
that delivers IP packets. By watching the demand of IP
communication of each node, it optimizes IP traffic (i.e.,
reduces latency and maximizes throughput) by appropriately
and dynamically changing the schedule of tokens.
This paper provides our evaluation work carried out on

Fig. 2. IP over RS485 with Master-Slave Token-Passing. The master node sends downward tokens to slave nodes and receives upward tokens replied by slaves.
They exchange IP packets along with tokens. The master node optimizes IP traffic on RS485 with dynamic priority-based packet control scheduler (DPPCS).

our RS485 testbed. The testbed has twenty RS485 slave nodes
connected on a 200-meter twisted-pair cable. We implemented
IP over RS485 and DPPCS, and evaluated (1) packet buffering
duration at slave nodes, (2) throughput and (3) tolerance forsimultaneous packet transmission. In facility networking, wesometimes collect sensor readings with, for example, 1 minuteinterval. The evaluation of the tolerance for simultaneoustransmission is for such a case, where all the devices may
send packets simultaneously.
This paper is organized as follows. Section II describes
the architecture we target in this paper. Section III introduces
DPPCS which we designed for the target network. Section IVshows our evaluation work. We provide discussion and related
works in section V, and conclude this paper in section VI.
II.

IP OVER RS485 WITH M ASTER -S LAVET OKEN -PASSING

Figure 2 shows the architecture of IP over RS485 withmaster-slave token-passing. The IP router in this figure has twointerfaces for wide area network (WAN) and local area network(LAN). Here, the LAN is implemented on RS485 network. The
LAN-side interface of the router works as a master node for
the RS485 link. The devices connected to the link work as
slave nodes. They have unique IDs to be addressed on thelink. They also have IP addresses, and they can communicate
with hosts over the IP network.
A. Token for IP packet delivery
We introduce token, which delivers an IP packet over
RS485. A token is a small message exchanged between themaster and one of the slaves on RS485. Figure 3 shows thedata structure. It is organized with downward/upward (D/U)
bit, slave ID, length of IP packet field, IP packet, and CRC
checksum. If the D/U bit is 1, this token is for downward,
which means from the master to the slave specified by theslave ID. If the D/U bit is 0, this token is for upward, meaningthat it is going to the master from the slave specified by theslave ID. A token can carry one IP packet from the master toFig. 3.

Token frame format for IP packet delivery on RS485

the slave or from the slave to the master. The length field tells
the length of the IP packet, if this is 0, no packet is followed
by. The data frame is closed with CRC checksum to detect theerror which may occur during the transmission over RS485.

B. Master NodeTo control the delivery of IP packets on RS485 link, themaster has a dynamic priority-based packet-control scheduler(DPPCS) and queues for outgoing IP packets. It sends a
downward token to a slave specified by DPPCS, and receives
an upward token replied by the slave. If there are packets forthe slave in the outgoing queue, the master attaches the one
to the downward token before sending. If the upward token
contains a packet, the master receives this packet and passes
it to the forwarder of the IP router.
To more formally describe, let s be an identifier of the slavenode, that DPPCS has provided as the next target to access. Let
Q be the set of the queues for outgoing IP packets. qs (∈ Q)
represents the outgoing queue that buffers the IP packets for s.
We denote tds a downward token to slave s, and tus an upward
token from slave s.
The master pops up a packet p from qs . Then, the mastergenerates a token tds with attaching p and sends it over theFig. 4. Scheduling of tokens on RS485 by DPPCS. ↓ and ↑ means downward
and upward tokens respectively. (a) When no packets are exchanged, DPPCS
gets priority queues as P0 = [s1 , s2 , s3 , s4 ] and P1 = []. In this form,
tokens are equally distributed to the slave nodes. (b) When only s1 makes
IP communication, DPPCS gets priority queues as P0 = [s2 , s3 , s4 ] andP1 = [s1 ]. Then, token is passed to s1 more frequently.

RS485 interface with turning it to transmission mode 1 . Here,if p is null (i.e., no packet is contained in qs ), the master does
not attach it to tds , but sends it over RS485 nonetheless. Aftersending tds , the master changes the interface to listen mode, andreceives the token tus responded by the slave. If tus contains an
IP packet, it posts the packet to the forwarder of the IP router.
Here, the master notify the information whether tds and tus
contain IP packets or not to DPPCS for planning the scheduleof tokens (see Section III).
C. Slave Node
We assume that a slave node has an application (APP)– a software instance, which manages sensors and actuators.
A typical APP in facility networks, reports sensor readings
to remote IP hosts, or receives actuator control signals fromremote IP hosts. To exchange IP packets from such remote
hosts, a slave has buffers for outgoing IP packets and incoming
IP packets.
1) Outgoing Buffer Interfacing: When an APP wants tosend an IP packet, it just puts the packet to the outgoing buffer.
Then, when the slave replies an upward token tus , it attaches
the packet to tus before sending. In this way, an IP packet sentby an APP goes to the IP router.
2) Incoming Buffer Interfacing: If a downward token tds
from the IP router contains an IP packet, the slave pushes thepacket to the incoming buffer. An APP receives the packet
from the incoming buffer. In this way, an IP packet delivered
over the IP router goes to an APP.
III.

DYNAMIC P RIORITY-BASED PACKET-C ONTROLS CHEDULER

We introduce dynamic priority-based packet-control scheduler (DPPCS). DPPCS generates the next slave ID, which themaster should pass a token to. DPPCS increases the throughput
of IP communication by dynamically changing the form ofproviding tokens to the slaves which need communication.
1 Please remind that RS485 is a half-duplex communication media. A node
has to change the interface into transmission mode from listen mode whensending.

Algorithm 1: DPPCS Generation of the Next Slave ID
t: an integer that represents a virtual clock for this algorithm.
initialized to 0 only at the first execution.
Ti : a constant integer that represents an interval on the virtual clock
for providing a slave from Pi
Pi .size(): the size of Pi
Pi .pop(): pops up the queue.
Pi .push(s): pushes s to the queue.
skipi : a boolean variable initialized to false at the first execution.
1: while true do
2:
foreach i ∈ {1, 0} do
3:
if Pi .size() > 0 ∧ t mod Ti = 0 ∧ ¬skipi then4:
skipi := true5:s := Pi .pop()
6:
Pi .push(s)7:
return s
8:
end if
9:end foreach10:
11:
t := t + 1
12:
foreach i ∈ {1, 0} do
13:
skipi := f alse14:
end foreach
15: end while

DPPCS defines two queues, which we denote by P0 and P1
in this paper. Both are the queues that contain slave IDs. 0 or 1
is intended for priority level. P0 has the slaves to access withpriority 0. P1 has the slaves to access with priority 1, whichmeans more frequent access. For example, if they are given
as P0 = [s2 , s3 , s4 ] and P1 = [s1 ](si ∈ S), the master passes
token to s1 more frequently than s2 , s3 and s4 (see Figure 4).
Here, S is the set of all the slaves available on RS485 link.
Whether si locates in P0 or P1 depends on the statistics of
IP-layer communication on slave si . If any tokens tdsi or tusi
holds an IP packet, DPPCS takes si from P0 , puts si to P1 ,and sets the validity time of si for P1 to PRIORITY TTL.
PRIORITY TTL is a constant value that how long, DPPCS
should consider, the slave makes IP communication after thelast IP packet exchange: e.g., 2 seconds. If there are no packet
exchange with si for PRIORITY TTL, DPPCS takes si from
P1 and puts si to P0 .
Algorithm 1 defines the DPPCS’s generation of slave IDs.
This algorithm is based on a virtual clock t, which increments
until finding the next slave ID. P0 and P1 have their own
interval of providing their slaves on the clock, which we define
by T0 and T1 . By setting T1 < T0 , P1 provides their slaves
more frequently than P0 does.
IV.

E VALUATIONThis section provides our evaluation work on IP over
RS485 with DPPCS. We have measured (1) buffering durationof IP packets at slave nodes, (2) throughput of IP traffic and(3) tolerance for simultaneous packet transmissions.
A. Experiment Setting
We have developed a testbed for IP over RS485 networking
as Figure 5. This testbed is organized with 20 micro-controller
boards (#1, #2, ..., #20), two IP routers, one host, and one
log server. The boards have RS485 and Ethernet interfaces.
We connected the RS485 interface to the testing network (i.e.,
RS485 network), and the Ethernet to the management network;
we used this management network for collecting experimentlogs. We have programmed our prototype slave node, andFig. 5. IP over RS485 Testbed Configuration. We connected 20 micro-controller boards to RS485 network. We setup an IP router developed for our IP
over RS485, installed application software on the host. The cable length from the router to slave #20 was 200 meters. The boards were also connected to the
management network for collecting experiment logs.

TABLE I.

H ARDWARE CONFIGURATION OF THE EXPERIMENT

Node
Slave

Type
Hardware
RS485 Interface
HardwareOperating System
USB-RS232C Adapter
HardwareOperating System

IP Router(Ethernet↔RS485)
Host

Description
Arduino Mega 2560 Compatible
LTC1485 Chipset
Lenovo ThinkPad T60
Ubuntu Linux 12.04 server
FTDI FT232RL Chipset
Lenovo ThinkPad X200s
Ubuntu Linux 12.04 server

installed it to the boards with assigning identifiers from #1
to #20 (so, all the 20 boards have worked as the slave nodes).
We have also programmed our prototype master node on serialinterface and on Linux TUN/TAP interface. We installed andexecuted it on a laptop, which had USB-RS232C serial adapter
and RS232C-to-RS485 converter, using the laptop as an IP
router. Please refer to Table I for the detailed configuration.
We connected each node with 10 meter twisted-pair cables
in cascaded manner as the Figure 5. Thus, the total cable lengthfrom the master to slave #20 was 200 meters.
In the following experiment, we have configured the serialinterface for RS485 with 115.2kbps, no parity and one stop
bit. We have set PRIORITY TTL=2000 [msec], T0 =100 andT1 =10.
B. IP Packet Buffering Duration
In our IP over RS485 network, buffering of IP packets
is necessary to actually transmit them on RS485 link. As
buffering makes some delay for the delivery of IP packets,
we have evaluated the buffering duration of IP packets on our
IP over RS485 network. In the experiment, we have focusedon the time of sending packet from a slave node. We measured
the duration between the time that an application on a slave
node generates an IP packet, and the time just before the slave
node sends the upward token which carries the packet.
In this experiment, we have setup two cases for the patternof IP packet generation: (1) Long-Interval Case and (2) ShortInterval Case. In the long-interval case, the application has sent
packets with 4 second interval, whereas in the short-intervalcase, 1 second interval. As the network works for 2 seconds
for DPPCS priority control, we have expected that the packets

in the long-interval case will not be prioritized, but the packets
in the short-interval case will be prioritized. To evaluate thepriority control scheme in more detail, we have also changed
the number of active neighbor slaves. ”active neighbor slaves”
were the nodes which sent 32 byte packets every second, whichwere expected to be prioritized by the DPPCS.
The active neighbor slaves do not include the measurement
node. We have used slave (#20) for the measurement of thebuffering duration, and other nodes for active neighbor slaves.
We used 64-byte long packet with more than 250 samples forthe measurement.
Figure 6(a) shows the evaluation result of the average
duration. When there were no active neighbor slaves, theaverage buffering duration for long and short-interval cases
were 50.0[ms] and 2.58[ms] respectively. This was because,in the long-interval case, when the application generated an IP
packet, DPPCS scheduled tokens to every node equally, but inthe short-interval case, it scheduled most of the tokens to themeasurement node.
When there were one active neighbor slave, the average
duration changed to 429[ms] and 5.06[ms]. This was because,in the long-interval case, DPPCS scheduled most of the tokens
to the active slave and less token to the measurement node.
In the short-interval case, tokens scheduled by DPPCS werebalanced with the active neighbor slave and the measurement
node.
As the number of active neighbor slaves increased, theaverage buffering duration of the long-interval case decreased,
this was because the number of slaves managed by priority
queue 0 was decreased, and it got more chance to be scheduled
in turn. The average buffering duration of the short-intervalcase increased, and when almost all the nodes were active, thebuffering duration for long-interval and short-interval becamealmost the same.
Figure 6(b, c) show the buffering duration for each IP
packet. These graphs show how the standard variations of thedurations (drew as error bars in Figure 6(a)) are large.

Fig. 6. Buffering duration of IP packets at slave’s outgoing queue. (a) Average duration in long-interval and short-interval cases to the number of active
neighbors. The error bar shows the standard variation of individual packet buffering duration. (b) Individual packet buffering duration in long-interval case. (c)Individual packet buffering duration in short-interval case.

As the number of active neighbors increased, the throughput of the IP traffic decreased. This result indicates that the
DPPCS has shared RS485 resource to other active nodes as
we intended.
D. Tolerance for Simultaneous Packet Transmission

Fig. 7. Throughput of IP traffic from #20 to the Host. DPPCS scheduled
tokens so as to share the bandwidth among active nodes.

C. Throughput of IP Traffic
Next, we have evaluated the throughput of IP traffic fromslave #20 to the host. In this experiment, we have programmed
an application that aggressively sends IP packets to the host.
This application immediately generated a packet when thesending buffer was ready to store it. We have setup two cases
for traffic measurement: 32 byte packet case and 64 byte packet
case. For both cases, we measured the traffic that slave #20
had sent for more than 3 minutes. We also changed the numberof active neighbor slaves, which sent 32-byte packet every
second, to see how DPPCS’s algorithm shared the bandwidth
when the network had several active nodes.
Figure 7 shows the result. With no active neighbor slaves,the node achieved the best performance for both cases. For
example, in the 64 byte case, it has achieved 6532 byte persecond. As we use 115.2kbps with 1 start bit and 1 stop bit
on RS485 link, this throughput corresponds to 56% use of
the RS485’s capacity. As RS485 is a half-duplex media andthe link-layer has overheads for token exchanges, this result
indicates that DPPCS is adequately controlling tokens so as tomaximize the bandwidth for active nodes.

Finally, we have evaluated the loss and latency of packet
delivery in simultaneous communication case. To carry out thisexperiment, we have implemented the following application
instances on slave nodes (192.168.1.{1-20}) and the host
(192.168.2.1). Each slave has sent an UDP datagram (i.e., IP
packet) every 5 second simultaneously with other slaves tothe host, and the host logged the received datagram with its
timestamp. Each datagram has contained sender’s slave nodeID, and the serial number of the datagram, which increments
every time the slave sends it. To synchronize the applications
on slaves to generate datagrams simultaneously, we havemodified the master to insert a small (= 5 octet) broadcast
token on RS485 every 5 second. All the applications on theslaves have received this token, and then they have composedand sent UDP datagrams to the host at the same time.
We have carried out this experiment for about 70 hours
from 2014-04-18 16:30. The length of the each IP packet
exchanged in this experiment was 64 byte.
There was no packet loss during the experiment. Totally,
the application instance of the host received 1,008,000 UDP
datagrams from the slaves during the experiment. We havechecked the slave IDs and the serial number of the messages,
and found that the host received 50,400 datagrams from eachslave without any loss (i.e., 100% delivery).
Using the log, we developed the distribution of delivery
rate on latency-axis for receiving 5, 10, 15 and 20 datagrams
after the first datagram arrival (see Figure 8). This resultshows that it has achieved the delivery of 20 datagrams sent
simultaneously from the slaves to the host within 1.2 seconds,
which is acceptable in many monitoring applications.
These results indicate that our IP over RS485 network has
a great tolerance for simultaneous packet transmissions.

We carried out evaluation on our RS485 testbed, organizedwith 20 slave nodes over 200 meter cable. With baudrate
115.2kbps, our prototype system (1) diminished the duration of
IP packet buffering at slave node to 2.58[ms], (2) maximized
the throughput to 6532 byte per sec, (3) achieved no packet loss
over 70-hour experiment in a simultaneous transmission case(20 nodes and 5 second interval). DPPCS balanced the traffic
among active communication nodes, with providing moderatelatency for getting-active nodes.
R EFERENCES[1]

Fig. 8. Delivery rate vs. latency for delivering 5, 10, 15 and 20 datagrams
sent simultaneously. Packets from all the slaves were delivered within 1.2
seconds.

[2]
[3]

V.

D ISCUSSION AND R ELATED W ORK

The Internet protocol (IP) is considered to be a key technology for implementing a Smart Grid [7], [16]. Smart Gridis being built on the IP infrastructure – for collecting meteringvalues [14], [17] and for controlling building facilities andhouses [5], [15], [1]. There are many kinds of communication
media possible to use here depending on the target field of
deployment: e.g., Ethernet, GPRS, power-line communication(PLC), IEEE802.15.4 and RS485. IP achieves interoperability
integration of those different communication media, which isnecessary in the development of Smart Grid.
RS485 is known as a well-matured, low-cost and reliable
wired communication media for monitoring and controlling
facilities in buildings. Hui-juan et. al. [10] studied the implementation of RS485 over UDP in order to access remote
RS485 device. Yongpan et. al. [17] developed a prototype
building energy management system using RS485 devices overthe Internet. Those works integrates RS485 devices on theInternet protocol but they do not deliver IP packets to end
devices. As for IP over RS485, which delivers IP packets over
RS485 line, according to [4], [3], Internet-0 project [9], [8]has studied IP over RS485 though the detail is not provided in
the literature. In IETF’s 6man working group, Lynn et. al. [11]drafted transmission of IPv6 over MS/TP networks intended
to ”IPv6 over RS485”, but this internet-draft is expired andthere seems no evaluation work.
In this paper, we have identified the possibility of IP
over RS485 architecture, proposing a dynamic priority-based
packet-control scheduler (DPPCS). We implemented the architecture, carried out experiments using our RS485 testbed, anddemonstrated that it shared the RS485 resource among active
nodes reducing latency and increasing the throughput as we
intended. We also showed its great tolerance for simultaneous
packet transmissions.
VI.

C ONCLUSION

We proposed and studied IP over RS485 intended to enable
IP-based facility networking over RS485. With master-slave
and token passing scheme, we introduced a dynamic prioritybased packet-control scheduler (DPPCS) that provide RS485
resources to the nodes which need IP communications.

[4]

[5]
[6]
[7]

[8]

[9]
[10]

[11]
[12]
[13]
[14]

[15]

[16]

[17]

B. Adebisi, A. Treytl, A. Haidine, A. Portnoy, R. U. Shan, D. Lund,
H. Pille, and B. Honary. Ip-centric high rate narrowband plc for smart
grid applications. Communications Magazine, IEEE, 49(12):46–54,
2011.
K. Bender. Profibus: the fieldbus for industrial automation. PrenticeHall, Inc., 1993.
N. W. Bergmann and P. J. Robinson. Server-based internet of thingsarchitecture. In Consumer Communications and Networking Conference(CCNC), 2012 IEEE, pages 360–361. IEEE, 2012.
N. W. Bergmann, M. Wallace, and E. Calia. Low cost prototyping
system for sensor networks. In Intelligent Sensors, Sensor Networks andInformation Processing (ISSNIP), 2010 Sixth International Conferenceon, pages 19–24. IEEE, 2010.
H. Broberg et al. Internet-based monitoring and controls for hvac
applications. Industry Applications Magazine, IEEE, 8(1):49–54, 2002.
S. T. Bushby. Bacnet: a standard communication infrastructure forintelligent buildings. Automation in Construction, 6(5):529–540, 1997.
X. Fang, S. Misra, G. Xue, and D. Yang. Smart grid - the new andimproved power grid: a survey. Communications Surveys & Tutorials,
IEEE, 14(4):944–980, 2012.
N. Gershenfeld and D. Cohen. Internet 0: Interdevice internetworkingend-to-end modulation for embedded networks. Circuits and Devices
Magazine, IEEE, 22(5):48–55, 2006.
N. Gershenfeld, R. Krikorian, and D. Cohen. The internet of things.
Scientific American, 291(4):76, 2004.
J. Hui-Juan and G. Zheng-hui. Research on the technology of rs485
over ethernet. In E-Product E-Service and E-Entertainment (ICEEE),2010 International Conference on, pages 1–3. IEEE, 2010.
K. Lynn, J. Martocci, C. Neilson, and S. Donaldson. Transmission of
ipv6 over ms/tp networks, 2012.
I. Modbus. Modbus application protocol specification v1. 1a. North
Grafton, Massachusetts (www. modbus. org/specs. php), 2004.
G. Mulligan. The 6lowpan architecture. In Proceedings of the 4thworkshop on Embedded networked sensors, pages 78–82. ACM, 2007.
J. Wang and V. C. Leung. A survey of technical requirements andconsumer application standards for ip-based smart grid ami network.
In Information Networking (ICOIN), 2011 International Conference on,
pages 114–119. IEEE, 2011.
C. Warmer, K. Kok, S. Karnouskos, A. Weidlich, D. Nestle, P. Selzam,
J. Ringelstein, A. Dimeas, and S. Drenkard. Web services for integrationof smart houses in the smart grid. Grid-Interop-The road to aninteroperable grid, Denver, Colorado, USA, pages 17–19, 2009.
Y. Yan, Y. Qian, H. Sharif, and D. Tipper. A survey on smart grid communication infrastructures: Motivations, requirements and challenges.
Communications Surveys & Tutorials, IEEE, 15(1):5–20, 2013.
C. Yongpan, M. Xianmin, Z. Jili, and L. Zhen. Development ofmonitoring system of building energy consumption. In Computer
Science-Technology and Applications, 2009. IFCSTA’09. International
Forum on, volume 2, pages 363–366. IEEE, 2009.