Global Standardization Activities
Trends in Home ICT Standardization
With home information and communications technology (Home ICT) services expected to become popular in the near future, we describe trends in the standardization of the platform and other technologies that will lead to the remote maintenance services needed for implementing Home ICT services.
NTT Cyber Solution Laboratories has been researching and developing a Home ICT platform for safe, convenient, reliable, and easy-to-use home information and communications technology (Home ICT) services with the aim of facilitating the spread of such services . The Home ICT platform uses OSGi  as its core technology. To become widely used by communication carrier service providers, however, the specifications of the platform’s major functions, such as the remote maintenance management, need to be extended and standardized to provide sufficient functionalities. In particular, since the Home ICT platform is expected to provide services such as remote management, which should efficiently support users in various environments connected to various home network devices from remote places, standardization of the home network devices is considered to be the key to success. From these viewpoints, we have been actively participating in standardization activities for OSGi and home network support technologies.
2. OSGi standardization activities
OSGi is a standard technology that enables software modularity in the Java language , . 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.
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.
1) Services can be provided by multiple vendors for various different operating systems on HGWs.
2) Services can be customized for each client.
3) Software developed by several different service providers can be operated on the HGW.
4) Services can be added, deleted, or updated without rebooting the HGW.
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).
2.3 Standardization of remote control function
The Home ICT framework uses TR-069  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.
1) Formulating guidelines for the mapping protocol defined by TR-069 and existing OSGi specifications
2) Defining a data model for remotely controlling the OSGi Framework
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.
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. Home network supporting technology standardization activities
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.
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).
Under the assumption that the controlled device of the UPnP device architecture  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) . 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.
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.
4. Concluding remarks
As trends in Home ICT standardization, we explained the current standardization activities in OSGi and the Home network support field. Prior to full-fledged introduction of Home ICT services, we will continue to perform our current standardization activities and foster the spread of terminals that conform to our specifications.