• 沒有找到結果。

Chapter 3. Home System Standards

4.5 System Components

4.5.2 eHome Gateway

Figure 4.7: eHome Gateway Category

According to the eHome Gateways are classified functionality and characteristics into three categories: Protocol Gateway, Control-Message Gateway, and Medium Gateway.

Figure 4.7 illustrates the relationship of eHome gateways. As shown in Figure 4.7, we can see that the Medium gateway is the subset of Control-Message Gateway and the Control-Message is the subset of Protocol Gateway. Therefore, the Protocol Gateway is the most powerful and complex eHome gateway of eHome system in our design.

4.5.2.1 Protocol Gateway

Figure 4.8: Architecture of Protocol Gateway

The term, “protocol”, refers to protocol sets, framework, or middleware of home system in this section. In the following paragraphs, we will use the term “protocol”

uniformly to represent middleware, framework and protocol. The home system protocols are more complex than common protocols, such as HTTP, SOAP and so on.

The protocols we defined have the following features:

Service registry/discovery or lookup service mechanism: The services of home appliances can be, control operations such as turn on TV, monitor status such as get lamp on/off status, Internet sharing, and so on. Once home appliances connect to a home system, they will use home system protocol to register its services automatically to a home system. Then each home appliance can utilize service discovery mechanism to find out the services provided by others which home appliances, and then home appliances can access the services.

Message system: The home system has the message system dedicated for processing the messages passing among home appliances of the home system. The message can be service registry/discovery, lookup service, Play-and-Play event etc. More complex or complete home systems generally have this system component, for example, HAVi home system.

Plug and Play mechanism: The user could use the services of the home appliance immediately when they plug a home appliance into the home system. It can straightly forward to know such home system needs to cooperate with service registry/discovery and service access mechanisms to complete full functions.

Comprise with multiple protocols: The home system protocol is comprises many different protocols. For example, UPnP standard needs TCP/IP, DNS (Dynamic Name System), HTTP (Hyper-Text Transfer Protocol), UDP (User Datagram Protocol), LDAP (Lightweight Directory Access Protocol), XML (eXtensible Markup Language), XSL (eXtensible Stylesheet Language), ARP (Address Resolution Protocol), etc. to implement UPnP home system.

High complexity

The home system protocol of OSGi, Jini, HAVi, HES and UPnP have these features described above. Therefore the Protocol Gateway is responsible for converting one home system protocol into another. For example, it converts HAVi protocol into Jini protocol. As shown in Figure 4.8, the protocol gateway has three types: “one to one”

in Figure 4.8 (a), “one to many” in Figure 4.8 (b), and “many to many” in Figure 4.8 (b). “One to one” type is a gateway which can convert only one protocol into eHome protocol. “One to many” type is a gateway which can convert multiple protocols into

eHome protocol. But “many to many” type is a gateway which can convert each protocol into every type of protocols. For example, it can convert Jini to HAVi, Jini to eHome, HAVi to Jini and so on.

The “many to many” type is a flexible architecture in eHome system. You can utilize this type of gateway to connect multiple home system protocols into eHome system. Besides, once the present eHome protocol needs to be changed into a new home system protocol. Then we just need to add the new protocol into this type of gateway to support the new protocol. On the other hand, “many to many” type is the most flexible gateway and can be adopted and modified quickly to fit the new eHome system.

4.5.2.2 Control-Message Gateway

Figure 4.9: Architecture of Control-Message Gateway

Control-Message Gateway is responsible for converting the control-message based protocol into another. The control-message based home system protocol defined in this paper has some of following features.

Figure 4.10: Request/Response and Notification/Event Diagram

Request/Response based mechanism: Figure 4.10 (a) is the diagram of request/response base mechanism. The server will send the request message to the client to access the services of the client. The client will perform the required operation and then return the result by response message. The HTTP is an example of protocol which uses the mechanism.

Simple notification/event mechanism: The notification/event is used when something occurs in home appliance. The home appliances (client) will report the message to server (control center) by notification/event mechanism. Figure 4.10 is the diagram of the simplest notification/event mechanism and it is usually adopted in control-message base home system protocol.

Static naming/addressing identification: The control-message base home system protocol usually use the static and unique identify formed by n-bits sequence number to represent the home appliances and home system components. For example, LnCP, the control protocol, proposed by Koon-Seok Lee, uses hex code “0x0”1 to represent “air conditioner”

product code in the physical address field of LnCP packet structure.

Represent command by unique ID or ASCII text string: The command is the request to access appliance services such as power on/off, turn lamp on/off and so on. The control-message base protocol usually use unique ID formed by n-bits sequence number or ASCII text string. For example, the command “Turn TV power on” is represented by unique ID-0x14, or ASCII text string-“CMD, TV, Power, ON”.

Short length of the message: The length of control-message base protocol is always short and it is usually smaller than 40 bytes. So it could be process and transmit quickly among home appliances. For example, the maximum, length of X10 protocol for PLC is 14 bits [65].

Low footprint: The control-message based home system protocol can be implemented in micro-controller base devices. The micro-controller base devices are usually with few bytes of RAM and ROM. For example, X10 protocol is such protocol and is implemented usually By PIC (Microchip company’s. micro-controller). Therefore, all home systems protocols whichever can be implement by micro-controller base devices fill the bill.

Others: The simple negotiation mechanisms such as retransmission,

administration, authentication etc. can be supported by control-message based protocol. But this kind of mechanisms is more complex.

4.5.2.3 Medium Gateway

Figure 4.11: Architecture of Meditm Gateway

Medium Gateway is the smallest scale of eHome Gateways. It is responsible for forwarding just only data/payload excluding specific headers of network interface from one home network interface into another one without any modification. For example, it forwards data from Ethernet to WLAN. On the other hand, the Medium Gateway does not have any protocol translation, but only forwards data. Usually, it is either implemented by the hardware only or both the hardware and little software (compare with other type of eHome gateways), even by a SoC chip.