Trends in Home ICT Standardization

2.1 Background

OSGi is a standard technology that enables software modularity in the Java language [2], [3]. It deploys various functions as software modules called bundles and operates the bundles in the runtime environment called the OSGi Framework. This framework provides a function that controls software life cycles, such as bundle installation, activation, suspension, and updating upon request from the managing bundles. It also provides security functions and a function for linking bundles.

The OSGi Alliance has been working to decide the specifications of the OSGi Framework and basic service bundles (Fig. 1). It has Expert Groups covering different fields. As of June 2006, the Core Platform Expert Group (CPEG) was fostering the development of OSGi Framework specifications and integrating all specifications, the Enterprise Expert Group (EEG) was dealing with extension of the enterprise server and middleware, and the Residential Expert Group (REG) was working on home networking.

Fig. 1. Structure of OSGi deployed in HGW.

2.2 Home ICT and OSGi standardization

Our developed Home ICT platform deploys OSGi in a software execution environment in a home gateway (HGW). We decided to deploy OSGi because it satisfies the following requirements.

NTT is fostering businesses that use the Home ICT framework. If new functions meet the standard specifications, then commercially available bundles conforming to the specifications can be used, which will greatly reduce the cost. Technology standardization within an appropriate range will be beneficial in fostering the penetration of the Home ICT framework. CPEG and REG are currently developing specifications for functions that have not been standardized but will need to be standardized since bundles will be provided by multiple service providers. Examples include remote control and competitive control (Fig. 2).

Fig. 2. Scope of OSGi standard specifications for Home ICT platform.

2.3 Standardization of remote control function

The Home ICT framework uses TR-069 [4] as a protocol for controlling HGWs remotely. TR-069, which was standardized by the Broadband Forum (BBF), is the de facto standard in the HGW field. We have proposed specifications for controlling the OSGi Framework and bundles based on TR-069. Our activities are summarized below and shown in Fig. 3.

Fig. 3. Remote management specifications proposed by NTT.

2.4 Standardization of competitive control

Under the Home ICT framework, services are expected to be provided by multiple service providers through the HGW. The OSGi specifications provide a structure for sharing functions among bundles and a structure for setting information required for bundles. However, setting such functions indiscriminately might cause information to leak to other providers or unexpected setting changes to occur. Therefore, OSGi offers a structure called an OSGi service that permits information to be shared among bundles through Java objects. A usage example of competitive control is shown in Fig. 4, which shows the example of service provider 1 using the OSGI service that controls the universal plug and play (UPnP) device provided by service provider 2. With conventional specifications, usage authority such as “the UPnP device’s OSGi service is available” can be granted to bundles, but more specific usage authority such as “only the UPnP device’s OSGi service that can control lights is permitted” cannot be granted. The Home ICT framework requires specific usage authority to be assigned to service providers. From this viewpoint, prior to the remote control method, NTT proposed extension specifications, which led to the publication of OSGi Core Specification Release 4.2 in September 2009. Since then we have been promoting other remote control specifications.

Fig. 4. Example of competitive control.

2.5 Cooperation with other standardizing organizations

In order to promote the acceptance of the released specifications, OSGi REG plans for specifications to be released as OSGi specifications taking into consideration other de facto standards used in the home area. OSGi REG exchanges notes with BBF, the Home Gateway Initiative, and UPnP at joint workshops on a regular basis to ensure that its effects are complementary without overlap.

3.1 Background

The number of end terminals that can be connected within home networks continues to increase. Those end terminals include various home appliances such as personal computers, game consoles, and hard disk recorders. Besides switching hubs and other conventional network devices, the number of communication media devices connected to home networks, such as power line communications modems, wireless modems, and coaxial cable modems, also continues to increase.

Home network services can suffer from degradations such as noise, other quality-related defects, or complete service failures. The locations of failures can vary. They could be somewhere on the wide area network (WAN) used for access, core networks, end terminals themselves within home networks (local area networks (LANs)), or access paths to end terminals. The causes of failures are also various.

When failures occur at multiple locations, it is difficult for users to identify the exact locations. To ensure that users can use those services safely, it is necessary to prepare a user support system that immediately detects failures and carries out appropriate remedial action. The failure location detection process should first identify the access route from the HGW to malfunctioning end terminals, and the end terminals on the route should then be investigated. In this process, it will be useful to have information about each terminal connected to the home network, such as the terminal type, manufacturer’s name, model name, and model number as well as a home network map (Fig. 5) showing the interface types and port numbers.

Fig. 5. Example of home network map.

Once the cause of a failure has been found, user support should be provided to enable firmware updating, restarting, and resetting. The next section explains the home-network topology identifying protocol (HTIP), which helps to create the home network map, and the UPnP device management (UPnP-DM) protocol that controls testing and setting for identifying the cause of failure.

3.2 HTIP standardization

This section outlines the HTIP technology that should be hosted by network devices and end terminals within the home network (Table 1).

Table 1. Functions and extension points of end terminals and network devices using HTIP.

Under the assumption that the controlled device of the UPnP device architecture [5] will be implemented, we formulated guidelines for the description format of a new definition of device information to be set in the device description document and existing elements. We chose UPnP because it is already present on a large number of existing end terminals, because it is expected to become more popular, and because it has an important function for giving notice of device information.

For the protocol for network devices that send packets, we chose the link layer discovery protocol (LLDP) [6]. We defined the vendor extension part for storing device information and connection structure information (synonymous with the media access control (MAC) address table). Since LLDP is a layer 2 (L2) protocol, it can be easily deployed in network devices without an L3 protocol stack. Another advantage is that LLDP can specifically process just the information sent, which greatly lightens the processing load.

The software that manages information within the home network (Manager) acquires information from end terminals equipped with HTIP and network devices (end terminals also have this function). This enables the connection structure of the home network to be defined (Fig. 6). The Manager can carry out connection tests between itself and end terminals and between itself and network devices.

Fig. 6. Operation of end terminal and network device based on HTIP.

This protocol was standardized by the Telecommunication Technology Committee (TTC), a domestic Japanese standardizing organization, at the end of August 2010 with the aim of achieving international standardization by ITU by the end of 2011.

3.3 UPnP-DM standardization

The UPnP Forum is fostering the standardization of the UPnP-DM protocol. This protocol enables test and control commands to be sent from other terminals within home networks to terminals that deploy UPnP-DM.

Control commands provided by UPnP-DM include tests for connection; quality checking; commands for setting; commands for restarting, resetting, and firmware updating; and commands for registering the receipt of device errors. Parameters for setting can include data models regulated by other organizations (e.g., TR-106 by BBF). UPnP-DM was standardized at the UPnP Forum in July 2010.

3.4 Application of protocols to support services

HTIP and UPnP-DM are protocols used within home networks. They can be used for on-site support services as well as remote support services since they do not rely on dedicated systems on the WAN side. In the case of on-site support, these protocols let maintenance personnel can diagnose customers’ home networks from their own terminals.

These protocols can be applied to remote support services in the following scenario: The HGW can be set to use UPnP-DM to monitor a certain terminal for error events on a regular basis. If an error occurs in the terminal, a notice will be sent to the HGW. A support center operator will receive the notice and respond to the error by taking remedial action from the remote site. To make this possible, we need collaboration technology that connects the protocol on the WAN side to the home network support protocol. Such collaboration technologies are currently being considered by BBF. Specifically, BBF has been working to standardize the TR-069 proxy technology that uses TR-069 for the WAN side and UPnP-DM on the LAN side.