CCDM: Central Controller-based Device Management Architecture and Methodto Split Management Scripts
Akihiro Sugiyama, Hideya Ochiai, and Hiroshi Esaki
The University of Tokyo
Graduate School of Information Science and Technology
7-3-1 Hongo, Bunkyo-ku, Tokyo 113-8656, Japansugi@hongo.wide.ad.jp

Abstract
This paper presents CCDM, a new architecture for management of devices, which collect environmental information and give effects to the environment. CCDM provides
easy management of devices and distributed execution ofgateways for sudden network disruptions. We separate themanagement system to the control plane and the data plane.
CCDM’s easy management is achieved by a logically centralized controller. The controller handles the control plane.
All the policy of device management and network information are stored to 2 kinds of scripts; service scripts andresource scripts. The controller transforms the policy towork distributedly at each gateway. Data plane is the data
communication between devices and gateways. Gateways,
which operate devices directly, works at distributed mannerbased on the policy on the controller.

1. IntroductionMore and more embedded devices, (i.e., sensors and actuators, have been connected to the Internet via gateways.
Embedded devices have their own unique protocols. Whenone wants to get information from a sensor and operate anactuator by the information, gateways need to take a role intranslating a device speciﬁc protocol to another. The role is
not just in protocol translation; gateways provide data processing and routing for devices. There being many devices
and gateways, distributed operation is desirable because of
the durability to the network disruptions or trafﬁc reduction. However, this distributed situation makes it difﬁcult toprovide easy management way because a user must know
all the network information, device protocols and device-togateway relations and decide where to allocate and executeapplications.
We propose Central Controller-based Device Manage-ment(CCDM) to tackle on those problems. We design
the control plane as centralized and the data plane as distributed. The central controller-based architecture allows
managers to operate devices through a simple interface
and applications to be executed in a distributed manner.
CCDM provides command set such as arithmetic operations, branch, loop and so on for system operators, which
are necessary in data processing. Additional command set
for device abstraction and communication between gateways is prepared, too.
We adopted the controller-based architecture byEthane[4], OpenFlow[1] and Cleanslate 4D[2]. Ethanemakes enterprise networks more manageable and more secure by a controller-based approach. A controller in Ethane
has the global network policy to govern enterprise networks. OpenFlow also adopts controller-based approach. It
aims to provide easy way for network researchers to run experimental protocols on campus networks. Active network[6, 7] looks alike from the perspective of programmablenetworks. A mobile agent[3] migrates its software anddata from one computer to another autonomously andkeeps its execution. Our point is in the adoption fo thecontroller-base architecture to device management.
Though CCDM’s controller-based architecture is similar
to architectures of these research, our policy description languages is completely different from them because our target
is in the management of devices. The way to describe management policies in CCDM is based on [5]. The high level
script language provides command set suitable for devicemanagement.

2. Controller-based System
2.1. System Requirement
We assume that various kind of devices are installedin buildings or campus networks. The management sys-12345<progn><chunk><INPUT from="WeatherSensor"/><post channel="A" name="INPUT"/></chunk>

67891011
12
13
14
15
1617Figure 1. Overview of CCDM System

18192021tem must satisfy the following 5 requirements. (1)protocol translation: Devices, which have different protocols
from device to device, must communicate with each other.
That is, protocol translation should be carried out. (2)data
processing: Data aggregation, conditional branch and any
data processing must be programmable. (3)communication
chain: From devices to devices procedure must be done in
distributed environment. (4)easy management: To enable
users to deploy services without considering underlying network and device protocols. (5)fault tolerance and trafﬁc balancing: Data plane must avoid single point of failure andtrafﬁc congestion.

2.2. CCDM Architecture
Figure 1 shows the architecture of CCDM. CCDM has
3 components; a CCDM controller, CCDM gateways anddevices.
A CCDM controller is a logically-centralized server. The
controller has service programs, which decide from which
device data come from and how to manage it, and resource
information, which is consisted of IP address of gateways,
device communication protocols, device-to-gateway binding and so on. The controller has two functions. One isto generate execution scripts for each CCDM gateway fromthe resource information and service program. One is todeploy those execution scripts to each CCDM gateway.
CCDM gateways are the gateways of each device. All
devices are bound to gateways. It is not a controller but
a gateway that operates devices in CCDM. Gateways work
under the direction of the controller with execution scripts.
Execution scripts shows the operation policy of each gateway. They derive from service programs and resource information stored at the controller. After deployment of execution scripts, a gateway gets data from sensors, calculate
it and give it to actuators.
Devices are set of sensors and actuators. They only
throw their data to a gateway and receive data from it according to their own protocols.

2223<chunk><catch channel="A" name="temperature"/>
<if>
<lt>
<getq name="temperature"/><int>20</int></lt><progn><OUTPUT to="Buzzer"><ARG><byte>1</byte></ARG></OUTPUT></progn></if></chunk></progn>

Figure 2. Sample Service Script

2.3. Policy Description Languages
CCDM deﬁnes 3 scripts; service scripts, resource scripts
and execution scripts. All the scripts are in the form of XML
languages, but they have different functions.
Service scripts are the programming language of CCDM.
A user writes an application to a service script. Applicationsin CCDM include alert notiﬁcation, data delivery, data aggregation, and so on. Command set of service scripts arearithmetic operations, logical operations, branch, loop, abstract device communication, etc. The command set provide the appropriate way for users to manage devices.
Resource scripts store the information of the network; IP
address of gateways, device protocols, etc. Resource scripts
are deﬁned to complement service scripts in compilation ofthem. It is because service scripts cover up the underlying
network information, device speciﬁc communication protocols and device-to-gateway bindings: the service scripts
need to complement these detailed information.
Execution scripts are created by the compilation of service scripts and resource scripts. Execution scripts are theinstruction for CCDM gateways. An execution script works
at each CCDM gateway.

2.4. Programming by Service Scripts
Consider, for example, Bob wants to sound a buzzer
when the room temperature becomes above 20 degree. Bob
writes the program to a service script. Figure 2 shows theexample. The program is divided into 2 parts by the chunkcommands in the line 2 and 7. Generally a chunk can contain stateful data processing. The program gets data froma WeatherSensor by INPUT command in the line 4. IN-

1234567891011121314<host name="CCDM_A"><ip>192.168.1.2</ip><port><begin>10000</begin><end>20000</end></port><devicelist><device name="WeatherSensor" func="INPUT"><progn>......... [Device Specific Protocol]</progn></device></devicelist></host>Figure 3. Sample Resource Script
Figure 5. Experimental Network
any devices can be allocated to any gateways.
INPUT/OUTPUT need to be replaced because they only
represent the generalized device interface. They are replaced to the device speciﬁc protocols described at the resource script at Figure 3.
Post/catch are replaced to UDP datagram socket. The
destination IP address and port are decided by their channel
and resource information.

3. Experiment and Analysis
3.1. Experimental Network Environment
Figure 4. Mechanism of CCDM Compilation
PUT/OUTPUT commands provide generalized device communication API. In the line 4, the data is sent to the channel
named A by post command. Post/catch commands enablea program to exchange data between chunks. A channels isthe communication channel between chunks.
The other chunk receives the data from the ﬁrst chunk bychannel A in the line 8. It checks whether the data is above
20 or not in the line 9-20. If the data is over 20, the buzzer
makes a sound by the OUTPUT command in the line 17. If
not, it does nothing.

2.5. CCDM Compilation of Service Script
and Resource Script
Figure 4 shows the mechanism of the compilation ofscripts.
A service script is divided into several parts. The unit ofthe partition is a chunk. The controller allocates each chunkto gateway. The allocation mechanism is based on deviceto-gateway bindings. Because a device is always bound to agateway, a chunk with a device can be bound to the gateway
which is bound to the device. A chunk with no relation toWe implemented CCDM prototype. To test and evaluate
the prototype, we built the experimental network Figure 5 .
It is based on the real network at the Bld 2 of Engineering
Department, The University of Tokyo.
We prepared 7 test case applications. The applications are (1)Weather Display, (2)Multicast Data Delivery,(3)Weather Threshold Notiﬁcation, (4)Data Aggregation,(5)Several Source Data Aggregation, (6)Largest Value Update Notiﬁcation and (7)Updated Data Delivery.

3.2. Network Management CostFigure 6 shows the code size of the test case applications. The summation of the code size of 7 applications
with CCDM system is 1074. On the other hand, one without
CCDM system is 4539. The code size becomes 23.7% with
CCDM system. It shows that programming with CCDM
make it easy to deploy new application.

3.3. Durability to Network Failures
We assumed that 3 points of the network at Figure 5 weredisconnected suddenly.
Table 1 shows the continuity of the Weather Display Service when each 3 point of Figure 5 was disconnected. EvenFigure 6. Comparison of Code Size

Table 1. continuity of the service in disruption

With CCDM System
Without CCDM System

1°°×2°××3°°°Figure 7. Time of Compilation and Deployment of Service Scripts

and the data plane. We believe that CCDM’s controllerbased architecture and the script languages are suitable forthe device management.

References
if gateways lost their connectivity to the controller, they remain working. It is because the control plane and the data
plane is separated at CCDM system.

3.4. Time of Compilation and Deploymentof Service Scripts
Figure 7 shows time to generate a execution script fromthe compilation of service scripts and resource scripts. This
result shows that the controller compiles scripts and send
them to gateways within 2 seconds. We think that 2 seconds
waiting time is not so long for new application deployment.

4. Conclusion
We implemented the CCDM prototype and evaluated itat the experimental network. We conﬁrmed users can program it on a single script with generalized device access interface. Programming with CCDM reduced the code size by
76.3 percent in our test case applications. It is because users
program applications without knowing device speciﬁc protocols and underlying network information; they are stored
at resource scripts. Contrary to the programming with acentralized manner, CCDM enables the distributed execution of applications. Our prototype deployment of CCDM
showed that the centralized controller is not the single pointof failures because of the separation of the control plane[1] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,and S. Shenker. Ethane: Taking Control of the Enterprise.
In SIGCOMM ’07: Proceedings of the 2007 conference on
Applications, technologies, architectures, and protocols forcomputer communications, pages 1–12, Kyoto, Japan, 2007.
ACM.
[2] A. Greenberg, G. Hjalmtysson, D. Maltz, A. Myers, J. Rexford, G. Xie, H. Yan, J. Zhan, and H. Zhang. A Clean Slate
4D Approach to Network Control and Management. ACM
SIGCOMM Computer Communication Review, 35(5):41–54,2005.
[3] D. Lange and M. Oshima. Seven good reasons for mobileagents. Communications of the ACM, 42(3):88–89, 1999.
[4] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar,
L. Peterson, J. Rexford, S. Shenker, and J. Turner. OpenFlow:
Enabling Innovation in Campus Networks. SIGCOMM Comput Commun. Rev, 38(2):69–74, 2008.
[5] H. Ochiai and H. Esaki. Networked GPIO Control by HighLevel Languages and Protocol Translator. IPSJ Journal,
49(10):3451–3461, 10 2008.
[6] D. Tennenhouse, J. Smith, W. Sincoskie, D. Wetherall, andG. Minden. A Survey of Active Network Research. Communications Magazine IEEE, 35(1):80–86, 1997.
[7] D. Wetherall and D. Tennenhouse. Towards an Active
Network Architecture. Computer Communication Review,26(2):5–18, 1996.