eHome Protocol

An eHome protocol is the protocol used in eHome backbone.That is, eHome Room Centers and residential gateway adopt an eHome protocol to communicate and cooperate with each other. In our proposal, an eHome protocol should be chosen depending on demand. However, the choice of eHome protocol will lead designing some consideration and issues. For example, choosing HTTP as our protocol, we may need to construct TCP/IP network as our network infrastructure. Moreover, we also need the approach with URL-based naming to identify each home appliance of the whole home systems.

Besides, an eHome protocol will influence the capabilities of an eHome system.

For instance, when you choose a protocol without capability to support the mechanisms such as service registry, the services of the whole home systems cannot be dynamic registered. Therefore, you need to add services to every home system including eHome system manually when the new home appliances are added into the existed home systems. Hence every device of home systems can access the new services now. However, it is very hard to maintain this kind of system and the system is difficult to use for end users. For this reason, to choose a suitable protocol is very important for an eHome system.

Chapter 5.

Implementation

5.1 Introduction

We intend to construct a prototype of eHome system using current emerging technologies including Embedded System, TCP/IP, GPRS, WAP, Java and BlueTooth.

Furthermore, we have designed a control-message based eHome protocol – BHCP and integrated X10 home system into our prototyping. Therefore, we can evaluate the correctness and feasibility of our proposed home system, eHome system.

In our implemented prototype, it contains a eHome Server which plays the role of the eHome Residential Gateway, a X10 home system, several self-designed home appliances with different network interfaces, and eHome Room Centers which are responsible for playing a role of central control center of each room. We will introduce each system component of eHome system in Section 5.2 and the details of implementation of X10 home system in Section 5.3. Finally, Section 5.4 will mention how to integrate all of them into our eHome system prototyping.

5.2 System Components

Our prototype consists of many system components including one eHome Server as eHome Residential Gateway (eHome RG), two eHome Room Centers (eRCs), several self-designed home appliances. The eHome Server provides the capability of remote access between public network and local home networks. The eRCs are responsible for integrating local home networks with eHome backbone and providing service discovery and access mechanisms. Moreover, we classify self-designed home appliance into two types IA according to their network interfaces: one is BlueTooth IA, and the other is RS-23/ASK-RF IA. Furthermore, we have integrated the existing famous home system, X10 home system, into our prototyping. We introduce them respectively as follows.

5.2.1 eHome Server

The eHome Server is a home server playing the part of the eHome RG of eHome system. It provides the capability of public network access. Therefore, the home appliances, which connect to eHome system, can share the resources of WAN through eHome Server. Besides, eHome Server is a HTTP server. End users can access the services provided by the home appliances that connects to eHome system through eHome Server when they are outside home.

Figure 5.1: eHome Server Architecture

5.2.1.1 Software Components

Figure 5.1 is the architecture of eHome Server. It comprises many software components including device drivers, protocol stack, Java Virtual Machine, Java Based WML Server, and implemented eHome system components. Each software component is introduced respectively following paragraphs:

32-bit CPU Based Hardware Platform: In consideration of the performance, we choose the 32-bit CPU based hardware as our platform.

The hardware platform must contain the network interface required by the residential gateway. For example, if the residential gateway uses the ADSL to connect to the WAN through PSTN, the hardware must contain the Ethernet interface. Besides, if the residential gateway adopts IEEE 1394 as its networking interface for local network (eHome Backbone), then IEEE 1394 interface is also consisted in the hardware platform.

Operating System: We consider that the residential gateway mush support Operating System (OS). The OS is a kernel of the system components of the eHome Server. It is responsible for providing a runtime environment for other software components. Moreover, we propose that the OS should contain at least capabilities of running Java Virtual Machine and device drivers of needed networking device.

Java VM: We choose Java to implement our HTTP server with capability of WML. Therefore, we need a Java runtime – Java Virtual Machine, which can be JVM or CVM depending on the requirement of the residential gateway and HTTP server. Beside, we add Java Virtual Machine to our eHome Server considering the feature of the platform independent of Java.

It will be very useful for the future implementation, improvement and integration.

BlueZ Protocol Stack: BlueZ [73] is an Open Source project of BlueTooth protocol stack distributed under GNU General Public License (GPL).

Qualcomm Incorporated developed it. The first version was released in 2001. Currently, the official BlueTooth protocol stack for Linux with kernel 2.4.x.

Communication APIs: The communications APIs are software components

above the network drivers. We package the network driver as the higher level interfaces considering in the portability, performance issues and ease programming. For example, if the original network driver was not implemented completely enough, and it just provides the read/write and open/close I/O functions. Therefore, we need to code a set API based on the original low-level functions to implement more functions, such as flow control and blocking/non-blocking I/O mechanisms. And we further package those implemented functions in the communication APIs.

Therefore, the upper software components can utilize this APIs to transmit and receive the data through the network interface. Besides, some network drivers comprise network drivers and some necessary functions for specific processing. In this case, we can implement it as the communication APIs to meet the requirements. For example, the ASK RF API comprises the RS-232 network driver and some specific functions to reducing the RF interference. So we implement the communication APIs to meet the requirements of ASK RF API as shown in Figure 5.1.

VR-RS232 Transport Layer: This software component is implemented considering the portability. We try to implement a virtual communication transport layer which can be ported to any kind of the network driver or communication APIs. Once your platform replaces the old network interface with a new one, you just need to modify the code of VR-RS232 layer to support the new network driver. The upper software components do not need to be modified any more. Besides, we can also implement the VR-RS232 to support the multiple network interfaces. The VR-RS232 of eHome Server is an implemented example in Figure 5.1

BHCP Protocol: This software component is responsible for parsing and processing the BHCP protocol. Each income/outcome BHCP packet is a handled by this component. The BHCP protocol is the lightweight control protocol for controlling home appliances. More details of BHCP protocol will be discussed later.

JNI Communication Adaptor: JNI Communication Adaptor is implemented as a DLL (Dynamic Linking Library) following the standard of Sun JNI interface. Therefore, the Java programs can utilize the resources

of DLL, which is implemented by native code (non-Java code). In our implementation, Java based WML Server can transmit a BHCP control message to control the home appliances or get the status of the home appliances via the JNI Communication Adaptor.

Java Based WML Server: The WML server is implemented in Java. It is a HTTP server with capability of processing WML content. Professor S.K.

Jeng implemented the part of HTTP request processing of the server coded in Java. The current WML server supports the GET and POST method.

However, we are responsible for implementing the part of the CGI function of the HTTP server. The CGI function consists of some Java classes (JNI API Package coded in Java) and a JNI Communication Adaptor, a dynamic library (DLL in Win32 version, so library in Linux version) coded in C.

Figure 5.2 shows the flow char of HTTP request processing in our WML server. Until now, we are able to control the home appliance via the http request sent from the client, such as mobile phone with WML Browser, whenever user is either inside or outside home. For instance, when end users want to control home appliance outside home. They can connect to eHome Server and sends a HTTP request via WML Browser of mobile phone via GSM/GPRS wireless network. Then the HTTP request will be sent to eHome server and processed by server. The example of request is

“http://140.112.28.198:80/?spaceUnit=MediaRoom&appliance=Linux_TV

&status=53#Linux_TV”. The server will call the related JNI function provided by JNI Communication Adaptor library to process and parse the CGI script. Then server sends the control request to corresponding appliance, TV in this example, through certain communication interface, such as RS-232 or Ethernet. The TV will activate according to the control request and return the processed result back to eHome server. Finally, the server combines the WML contents with the returned result into a completed WML page, and then sends this WML page back to the mobile phone by HTTP response protocol via Internet via GPRS/GSM wireless network.

Figure 5.2: Flow chart of HTTP request processing of WML Server

eHome RC: It is a software component, which is responsible for all functions of eHome Room Center mentioned in Chapter 4. The more details are described in Section 5.2.3.

X10: It is also a software component. It is responsible for integrating with X10 system. Thereby, we can also access the services provided by X10 system through it. The more detail in mention in Section 5.3.

5.2.2 eHome IA

We have designed two types of eHome IAs ourselves. One is RS-232 IA. It also supports the capability of wireless communication by adding ASK RF module. On the other hand, it could transfer data by wire RS-232 interface or wireless ASK-RF module. ASK RF module is a very cheap RF module and is usually used for remote-controlled devices, such as remote-controlled aircraft, and wireless home appliances.

The other eHome IA is BlueTooth IA. It is a home appliance with BlueTooth wireless interface. We further classify BlueTooth IA into two categories according to their capabilities: one is Simple IA, and the other is Advanced IA. Simple IA is a low-priced IA and is managed by Advanced IA. Besides, the Advanced IA has full capabilities of BlueTooth, but Simple IA does not. In other words, the relationship between Simple IA and Advanced IA is client-server architecture. The simple IA can have full BlueTooth capability through Advanced IA. We will introduce more details later.

5.2.2.1 RS-232 IA

Figure 5.3 shows the hardware function block of RS-232 IA. RS-232 IA is a self-designed home appliance with the hardware and software design. Currently, we

have designed four kinds of appliances: simple lamp, IR_URC, dimmer and SAC (Simple Air Conditioner). Our designed RS-232 IA is 8052-based platform with the ASK RF module for providing wireless communication. The simplest IA, simple lamp, can turn on/off the lamp (AC) and get the status of the lamp (on/off.). Its hardware function block diagram is shown in Figure 5.3 (a).

IR_URC combines with commercial IR URC (Universal Remote Controller) as shown in Figure 5.3 (b). We can convert the BHCP control message received from ASK RF module to IR control signal, which is sent by the commercial IR URC, through IR_URC. Therefore, we can utilize IR_URC to control IR remote-controlled appliances, which are controlled by the commercial IR URC, such as the A/V device and TV.

The dimmer, a home appliance which can sense the current illumination and adjusts the illumination of the light, consists of the Triac Power Control, photosensor, 8052, the ASK RF module and 7 segment display circuit as shown in Figure 5.3 (c).

Therefore, you can adjust the illumination of the light and get the current illumination via this dimmer.

The simple air conditioner appliance can sense the temperature and turn on/off cooler/heater according setting temperature. It simulates the behavior of the air conditioner. The hardware function block of SAC is shown is Figure 5.3 (d). We adopt the NTC resister as our temperature sensor and the relay control circuit for AC power on/off switch. Therefore, we can set the expecting temperature to SAC, and SAC will turn the heater/cooler on/off based on setting temperature ranged +/- 3℃. For example, if the sensed temperature is 23℃ but the expecting temperature is 20℃, then the SAC will turn the heater on and the cooler off due to expected temperature is greater than the sensed temperature 3℃. On the other hand, if the sensed temperature is 17℃, the SAC will turn the cooler on and the heater off.

☆ Hardware Function Block

Figure 5.3: RS-232 IA Hardware Function Block

☆ System Architecture

Figure 5.4 illustrates the system architecture of RS-232 IA. RS-232 IA comprises many software components. Each of the software components is coded in C and compiled with KEIL C compiler. BHCP protocol, ASK RF APIs and RS-232 driver are the same as the related software components of eHome Server. Besides the native drivers are firmware codes for driving the I/O device, such as LCD, 7-segment display and Triac power control. The entire code size is totally about 4k bytes (binary image size) and is embedded into the Flash ROM of 8052 as firmware.

Figure 5.4: RS-232 IA Software Architecture

5.2.2.2 BlueTooth IA

Another type of eHome IA is BlueTooth IA. It is a home appliance with the capability of BlueTooth communication. In this case, BlueTooth IAs can communicate with each other via BlueTooth. We have implemented two kinds of BlueTooth IAs according to cost and functionality. One is Simple IA that is also an 8052-based appliance; another is Advanced IA, which is ARM-based appliance.

BlueTooth Simple IA is an 8052-based appliance. We have implemented the subset of BlueTooth protocol stack. In this case, the implemented protocol stack needs more hardware resources than RS-232 IA. Therefore, we expand the ROM and RAM size of 8052. Currently, both of ROM and RAM size of designed BlueTooth Simple IA are expanded to 64 bytes. Besides, we separate IA’s hardware into two individual boards: one is 8052-based motherboard and the other is I/O expansion board considering in flexibility and convenience. Figure 5.5 depicts their hardware function block diagrams. In this case, I/O expansion board is hardware for controlling different appliances. Therefore, if you want to design the new appliance, you only need to redesign the I/O expanding board.

Because 8052 microcontroller provides UART interface and BlueTooth module has RS-232 interface. Therefore, we adopt RS-232 as the communication interface between 8052 and BlueTooth module. Moreover, the voltage level between UART and RS-232 is different. So we need to further convert the logic level signal of UART of 8052 to RS-232 voltage level through RS-232 converter circuit (for example, ICL232 or HIN232 IC). Consequently, 8052 can connect with BlueTooth module via UART via this converting circuit.

Furthermore, we combine three different hardware of distinct appliance into one I/O expanding board as shown in Figure 5.5 (a). We call it “3 in 1 IA”. It contains three appliances consisting of Simple Lamp, Simple Air Conditioner and Dimmer.

The function of these IAs are the same with RS-232 IAs excluding communication interface (replacing ASK-RF module with BlueTooth).

Figure 5.5 (b) is the hardware function of BlueTooth IA - BlueIR. It can covert BHCP control message from BlueTooth interface to IR signal sent by the commercial IR universal remote controller. Besides, it also contains LCD display, so you can display the messages on the LCD panel. We also reserve the expand I/O connector.

Hence, the hardware can be further expanded to implement more functions.

☆ Simple IA - Hardware Function Block

(a) BlueTooth Simple IA - 3 in 1 IA

(b) BlueTooth Simple IA – BlueIR IA

Figure 5.5: BlueTooth Simple IA HW Function Block

☆ Simple IA - System Architecture

Figure 5.6 depicts the system architecture of BlueTooth Simple IA. We can see that the obvious differences between RS-232 IA and BlueTooth Simple IA are BlueTooth protocol stack and hardware platform. To support BlueTooth communication, we need to implement BlueTooth protocol stack. We have implemented BlueTooth protocol stack, BlueTooth HCI and HCI UART Transport layer to support ACL/SCO data bi-directional communication. BlueTooth Simple IA has only parts of the functions of BlueTooth (ACL data communication), but BlueTooth Advance IA, which is ARM-based platform, has full functions of BlueTooth.

Figure 5.6: BlueTooth IA Software Architecture

☆ Advanced IA - System Architecture

As mentioned above, BlueTooth Advanced IA is an ARM-based platform. We have implemented it with iPAQ, a StrongARM-based PDA. Figure 5.7 illustrates the general system architecture of BlueTooth Advanced IA. The software components are almost the same as eHome Server excluding Home IA drivers and QT/Embedded. The function of BHCP Manager is the same as JNI Communication Adaptor in eHome Server. The only difference between them is BHCP Manager is fully coded in C but JNI Communication Adaptor has the functions following the JNI interface standard and one Java class declaring JIN APIs additionally.

Because of using iPAQ Linux as our development platform we adopt a Linux distribution – Familiar Linux for iPAQ platform.[77] It is also an open source project for developing a completed embedded Linux for iPAQ H3xxx series. Besides, we have developed a friendly user control interface based on QT/Embedded [75]. The QT/Embedded is an embedded Linux application development framework based on QT toolkit. It is a GUI development toolkit solution for the cross-platform and coded

in C++. QT and QT/Embedded are both developed by Trolltech Inc.[74] We adopt the open source version 2.3.2 as our current GUI development framework. We have implemented two application prototypes successfully. One is IR Wizard IA, and another is BlueURC. They are mentioned individually following.

Figure 5.7: BlueTooth Advanced IA General System Architecture

☆ Advanced IA – Management Architecture

Advanced IA has more powerful computing power. Therefore, we propose Advanced IA can play the role of manager for Simple IAs. It is responsible for managing Simple IAs by client-server architecture. Because of the limitation of BlueTooth Pico-net, each Advance IA can manage up to seven BlueTooth-based Simple IAs. Nevertheless, Advanced IA can connect and manage the legacy appliances with different network interfaces as many as possible. For example, Advanced IA can connect legacy IA with RS-232 or ASK-RF interface. The limited amount of Simple IAs is depended on the specification of Advanced IA. On other words, the interface between Advanced IA and Simple IA can be either BlueTooth or other network interfaces. Furthermore, Simple IAs can support fully BlueTooth capability through Advanced IA management.

Such approach can reduce the construction cost and it is more feasible. The similar approaches can be found in many home system standards, such as HAVi and Jini.

☆ IR Wizard IA

A sample implementation of BlueTooth Advanced IA, IR Wizard IA, is a IA which you can use to learn the IR signal of the legacy home appliances with IR

A sample implementation of BlueTooth Advanced IA, IR Wizard IA, is a IA which you can use to learn the IR signal of the legacy home appliances with IR