for Home Computing
with Virtual Overlay Netw orks
Daiki Ueno,Eiji Tokunaga, Hiro Ishik awa,Tatsuo Nakajima
Departmentof Information and Computer Science
Waseda University
3-4-1 Okub o Shinjuku Tokyo 169-8555 JAP AN
tatsuo@mn.waseda.ac.jp
Ichiro Satoh
NationalInstitute of Informatics /
Japan Scienceand TechnologyCorp oration
Abstract
Thepap erprop osesanapproachtosolvethesituation.
In ourapproach,we have develop ed amiddleware com-
p onenttoconnectseveralmiddlewareimplementingthese
object-orientedstandardsp ecicationsforhomecomput-
ing. Actually,our middlewarecomp onentmakesit p os-
sibletoconnecthomeappliancesadoptingHAVi,Jini,or
UPnP.Therefore,varioushomeappliancescancommuni-
cate witheach other.
1 Introduction
Our future home will have a lot of home appliances
such as TV andVCR,and these applianceswillb e con-
nected with each other. Several standard sp ecications
for home computing have b een develop ed recently, and
a lotof p eople b elieve that future homeappliances will
implement these sp ecications. However, for example,
Jini has b een develop ed several years ago, and we had
thought that several real appliances implementing Jini
app ear so on. Whyaren't theseappliances availablenow
? One of thereasons isthat ifanappliancecho oses one
standardsp ecication,itisnoteasytocommunicatewith
otherappliancesimplementingdierentstandardsp eci-
cations.
Thereareseveralapproachestosolvetheproblem.F or
example,aJiniandHAVigatewayhasb eendevelop edto
connectJiniandHAVidevices. However,theapproachis
veryad-ho c,andmanygatewaysshouldb e implemented
to connect dierent sp ecications. We needamoresys-
tematicapproach tosolvetheconnectivityproblem.
Thispap er prop osesamiddlewarecomp onenttocon-
nectvariousappliancesimplementingstandardsp ecica-
tionsforhomecomputinginasystematicway. Actually,
we have develop ed a middlewarecomp onent connecting
HAVi[2], Jini[4], and UPnP[3]. Our approach adopts a
virtualoverlaynetworkusingtheHTTPproto col,which
buildsanapplicationsp ecic networkontheInternet.
2 Design and Implementation
A key goalmotiv atingthe designof avirtualoverlay
network isto provideanapplication-sp ecic abstraction
for homeappliances overlaidon heterogeneousnetworks
such as IEEE1394,Blueto oth, andtheInternet. Inthis
section,wedescrib ethedesignandimplementationofour
currentprototyp esystemofthevirtualoverlaynetwork.
First, we present designissues and thesystem overview
of oursystem, then we show somecomp onents that we
have currently implemented. The comp onents showthe
eectiveness ofourapproach.
2.1 Design Issues
Theend-to-end argumentisasystemdesignprinciple
intheInternet. That is,sophisticatednetworkfunctions
are assumed to b e pushed to the edge of the network.
However,alltheedgesinthecurrentInternetaresophis-
ticatedcomputingdevices,b ecausesomeofthemarede-
signed for only theirown sp ecial purp oses, for example
home appliances, emb edded computers,and PDAs, and
thus maynothandlestandard proto cols intheInternet.
Therefore,someenrichnetworkfunctionsshould b esup-
p orted orenhanced inside thenetwork,ratherthansuch
stupid edges, and provide aseamless p ersp ective for all
edgesandsub-networks,evenwhensomeoftheedgesand
sub-networks arenotready fortheInternet. Ourvirtual
overlaynetworkframeworksupp ortsthefollowingfurther
functions.
The virtual overlay network framework is built
aroundanewnamingsystem. W eb elievethatappli-
ances should b e lo okedupaccording to theirinten-
tionalinformationsuchasfunctionalityandphysical
lo cations,ratherthantothingslikehardco dinghost-
namestoaddresses. Indeed,someappliances,which
donotsupp ortTCP/IP,cannothaveanyuniquead-
dressesavailableintheInternetandthusarerequired
to b e encapsulated byand identied through other
servers,whichcandirectlyconnectedwiththeappli-
ances.
Proceedings of the Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’02)
0-7695-1558-4/02 $17.00 © 2002 IEEE
and widely used in the current Internet. HTTP is
the proto col that underlies the World Wide W eb,
and so any web browser, by denition, can com-
municate using it. This communication o ccurs by
thebrowserusingURLsthatconformtoapredeter-
minednamingconvention. Ourvirtual overlaynet-
workframeworkshould easily andnaturallycontrol
access to, management of, corp orate various home
appliancesthroughanordinarywebbrowser. There-
fore,itneeds toenable homeappliancestoworkto-
gether withintheWeb space and tob e sp ecied at
URLs.
Some home appliances may often b e managed un-
derexisting service discovery systems formanaging
devices and services such as Jini and UPnP. These
systems areprop osed tofacilitatedynamicco op era-
tion amongdevices/services with minimaladminis-
trationandhumanintervention. Inordertob e able
to supp ort theimpromptu community,they should
provide the means to announce its presence to the
network, to discover services in the neighb orho o d,
and to access to services. Our virtual overlay net-
work frameworkoers aunied p ersp ective for not
only appliances but also existing service discovery
systems formanagingappliances.
Thevirtualoverlaynetworkframeworkshouldmake
extensive use of transco ding to p erform transfor-
mations on data in the network. This is b ecause
somehomeappliancesoftenhaveserious limitations
intheircomputationalresources suchas pro cessors,
andoutputandinputdevices. Theymaynotb eable
to directly handleenriched data,which they should
receive from and send to the network, withoutany
assists for transco ding that data fromexternalsys-
tems.
2.2 Architecture
The virtual overlay network framework consists of
homeappliances/servicesandapplication-levelgateways,
where some appliances are just application-sp ecic de-
vicesandthusdonotsupp ortTCP/IP.Eachapplication-
level gateway is implemented as a HTTP-based proxy
server, and can control more than one appliance, with
whichitcancommunicatedirectly. Also,thegatewaycan
b e treated as an access p oint which interfaces to more
than one appliance in an access network and provides
a translation service from HTTP to the corresp onding
commandsofitstargetappliances. Also,itcanexp ort a
genericsessioninterfaceofvariousappliancestotheInter-
net. Thatis,itactsasaclientwhenitestablishessessions
to the Internet and as a server when it accepts incom-
ingsessionsfromtheInternet. Also,theapplication-level
gatewaycansupp ortapplication-sp ecicservices, forex-
amplenaming,transco ding,andpacketforwarding.Ava-
rietyofhomeappliancescanb econnectedtoapplication-
level gateways and the ways of controlling these appli-
ances are not unied yet. Therefore, we intro duce the
etyandchangesofappliances. Anapplication-levelgate-
wayconsists oftwolayers. Thetoplayer consistsofthe
functionalitytosatisfyHTTPrequestsandvariousmo d-
ules that provide the logic to p erform web based tasks
such as authentication, and so on. When it receives an
HTTPrequestfromabrowser,oneofthemostappropri-
atemo dulesisselected toserve therequest. This mo du-
larapproachmeansthatitisp ossibletoinstalladditional
mo dulestoextendthegateway'sfunctionality. Thelower
layer uses our frameworkforaccessing to theactual ap-
plianceandsupp ortingservices.
2.3 Accessing Home Appliances from Web
browsers
Although our nal goal is to oer URL based inter-
facestoarbitraryapplicationsanddevices,wecannotcur-
rentlyturnallnetworkappliancesintoHTTPservers. In-
stead, each application-levelgatewaycontrols morethan
one appliance through their particular networks by of-
fering atranslation service fromURL-based expressions
to corresp ondingcommandsdesigned fortheappliances.
Typically,theweb-browser accesses remote hostsidenti-
ed in a URI by submitting a query request using the
standard HTTP GET mechanism, and receives the re-
sp onse fromtheURI,orsubmittingdatatotheURIvia
an HTMLformusing thestandard HTTPPOST mech-
anism, and receives the resp onse from the URI also in
HTTP. The gateway then carries out the necessary op-
erations or queries with the homeappliance. Whenthe
gatewayhasnishedtalkingtotheappliance,theresult-
ingdataispassed backtothebrowser.
http://some.where.com:8080/CEIL-LIGHT/!power=ON
The ab ove URL is a typical example of our nam-
ing convention. It invokes the gateway named as
some.where.com,whichislisteningonp ort8080byprior
agreement. TheCEIL-LIGHTelementsp eciesanelectric
light controlled under the gateway. The !power=ON el-
ement signals to the gateway and nominates a sp ecic
function,calledpowerprovidedwiththeONvaluebythe
appliance. TheURLis arequest toturn on theelectric
lightnamedasCEIL-LIGHT.
2.4 Integrating Home Net works
In this section, we describ e how to connect several
homenetworksthatprovidedierenthomenetworkpro-
to cols by using our virtualoverlaynetworks. As shown
in Figure 1, we assume that there are three home net-
works that are connected to the Internet via resp ective
application-levelgateways. Thesehomenetworksresp ec-
tivelysupp ortUPnP, HAVi,andJiniproto cols.
Application-levelgatewaysinour virtualoverlay net-
worksconsistfourcomp onents. Therstcomp onentim-
plementshome network proto colssuch as HAVi,Jini,or
UPnP. Thecomp onentb ehaves as one of homenetwork
devices. Forexample,ifacomp onentimplementstheJini
proto col,itb ehavesasaJinidevice. Thesecondcomp o-
nent implements the HTTP proto col. The comp onent
b ehaves asaWebserver.
Proceedings of the Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’02)
0-7695-1558-4/02 $17.00 © 2002 IEEE
,QWHUQHW ,QWHUQHW
+$9LQHWZRUN -LQL QHWZRUN
83Q3 QHWZRUN
$S*: +$9L
KWWSP\KRPHQHW KWWSIRREDUQHW
$S*: -LQL
KWWSDQ\ZKHUHQHW 9&5P\KRPHQHW
9LUWXDO 83Q3 GHYLFH DSJZ
DSJZ
DSJZ FDPHUDIRREDUQHW
9LUWXDO +$9L GHYLFH
XVHU 3'$
&DPHUD 9&5
79
$LU &RQGLWLRQHU
83Q3
$S*:
Figure 1: ConnectingHomeNetworks
The third comp onentimplementsa proto col transla-
tor. The translator converts b etween the HTTP trans-
action describ ed in the previous section and home net-
work proto cols. For example, theHAVi translator con-
vertsb othfromtheHTTPproto coltotheHAViproto col
andfromtheHAVi proto coltotheHTTPproto col. We
havealsoimplementedtheJini translatorandtheUPnP
translatorinourcurrentprototyp eimplementation.
Thelast comp onentisthe registrationmanager. The
registrationmanagercan b eaccessed bytheHTTPpro-
to col from a Web browser or a home network proto col
fromsomeappliancesthatimplementtheproto col. Ifan
applianceonahomenetworklikestob eaccessedfrommy
homenetwork,thenameoftheappliancethat we liketo
access shouldb eregistered onmyapplication-levelgate-
way. Thename can b e registered via either the HTTP
proto colorahomenetwork proto col. After theregistra-
tion,anewpseudohomenetworkdeviceiscreatedinthe
application-levelgateway. Thepseudodeviceregistersits
name inalo okupservice. Theroleof thepseudodevice
is to covert control commandsthat aredelivered on the
homenetworkto theHTTPproto col.
For example, let us assume that we like to control a
VCR device on a HAVi network from a PDA connect-
ingto aUPnPnetwork. IntheHAVinetwork,theVCR
device is registered as \VCR",and its application-level
gateway(HAVi ApGW) is registered as \apgw" in the
HAVi lo okup service. In the UPnP network, the PDA
devices is registered as \PDA"and its application-level
gateway(UPnP ApGW) is registered as \apgw" in the
UPnPlo okupservice.
Now,we liketo register theHAVi VCRdevice inthe
UPnPnetworkforcontrollingtheHAViVCRdevicefrom
the UPnP PDA device. From the PDA device, a user
registers the HAVi VCR device in UPnP ApGW as a
pairof\VCR"and\http://my.hom e.net/VCR"fromthe
Web browser on the PDA device. UPnP ApGW cre-
ates a pseudo UPnP device on UPnP ApGW, and reg-
isters \VCR" in the UPnP lo okup service. When the
PDA device likes to control the HAVi VCR device, the
PDA device tries to nd the VCR device viatheUPnP
lo okup service. The lo okup service returns a reference
to the pseudo device that is created on UPnP ApGW.
Then, acontrolcommandis deliveredto thepseudo de-
vice viatheUPnPproto col. Thepseudodevice converts
the UPnP request to the HTTPproto col, andforwards
Proceedings of the Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’02)
0-7695-1558-4/02 $17.00 © 2002 IEEE
part of \http://my.hom e.net/VCR/". HAVi ApGW re-
ceivestheHTTPrequest,andndstheVCRdevicewith
the name \VCR"that is sp ecied inthe le name part
of the URL via the HAVi lo okup service. Finally, the
commandis converted to the HAVi command, and it is
deliveredto thetargetVCRdevice.
Also, let us assume that we like to control a
Jini camera device from a HAVi TV device. In
this case, a user registers a pair of \Camera" and
\http://fo o.bar.net/Camera/"onHAViApGWusingthe
HAVi proto col,where theTVdevicendsHAVi ApGW
viatheHAVilo okupservicewiththename\apgw".Sim-
ilar to the previous example, a HAVi command is con-
verted to a HTTP command at HAVi ApGW, and the
HTTPcommandisconverted toaJini commandatJini
ApGW.
There isaprop osalto connect HAVi andJini viathe
HAVi-Jini bridge. However, the approach needs to im-
plement a lot of bridges if there are several home net-
workproto cols. Moreover,whenanew homenetwork is
prop osed, it is not realisticto create alotof bridges to
convert amongproto cols. Inourapproach,anew home
network proto col requires to implement a converter to
translateb etween theHTTPproto colandthenewhome
networkproto col.
2.5 Registering Remote Devices
One of the most serious problems of the current ar-
chitecture is the registration of remote devices. When
a user movesto other p eople's homes, itis necessary to
registerthenameofanappliancetouseitfromtheother
p eople'shomes. F or example,ifI like toaccess mytele-
vision from my friend's home, my television should b e
registered to thegatewayserver ofmyfriend'shome. It
seems that theapproach is notpractical. Moreover, ifa
user'homerequires tousemultiplehomenetworkproto-
cols,itisdiÆculttouseappliancesthatsupp ortdieren t
homenetworkproto cols.
Oursolutionto solvetheproblemistouseap ersonal
device to make the registration easy. In our approach,
each appliance returns a URL when a p ersonal device
sends arequest. Also, the p ersonal device can transmit
theURLtoagatewayserver whenauser visitstoother
p eople's homes. In oursystem,we are usinginfrared to
receive/transmit URLs. We b elievethat ourapproachis
very practical and makes the registration of appliances
very easy. Also, the approach can b e used as a generic
metho dtomove asmallamountof informationb etween
twoappliances.
3 Current Status
Currently, we have built a prototyp e system imple-
mentingthe prop osed architecture. The prototyp e sys-
temhasimplementedinJava,andis runningonLinux.
Thesystemcontainsthefollowingcomp onents.
Jini-basedclientprogram
UPnP-based clientprogram
Jini-basedTVcontrolsystem
UPnP-based Lightcontrolsystem
UPnP-based MP3player
HAVi-baseddigitalcamerasystem
Jini-basegateway
UPnP-based gateway
HAVi-basedgateway
The followingsystemallowsus to control theUPnP-
based Light control system, Jini-based TV control sys-
tem,andHAVi-baseddigitalcamerafromanyclientsys-
temsthatsupp ortsUPnP,JiniorHAVi. Also,thesesys-
tems can b e controlled from a standard Web browser.
Figure??showsourcurrentprototyp esystem.
4 Conclusion
In this pap er, we have prop osed a way to connect
object-orientedmiddlewareforhomecomputingwithvir-
tual overlay networks. The virtual overlay network de-
terminestheroutestodelivermessagesandconvertspro-
to cols and messages according to the characteristics of
networksandappliances. Wehave describ ed severalsce-
narios to showthe eectiveness of the prop osed virtual
overlaynetwork andhavepresented theimplementation
ofthecurrentprototyp esystem. Thedetaileddescription
ofourworkcan b efoundin[1]
References
[1] T. Nakajima, H.Aizu, I.Sato, D.Ueno, \A Virtual
Overlay Network for Integrating HomeAppliances",
In Pro ceedings of the International Symp osium on
ApplicationsandtheInternet, 2002.
[2] HAVi Consortium, "HAVi Home Page",
http://www.havi.org/.
[3] Univeral Plug and Play Forum,
http://www.upnp.org/
[4] JimWaldo,\AliveandWell: JiniTechnologyTo day",
IEEEComputer,V ol.33,No.6,2000.
