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.