JP5095529B2 - Heterogeneous smart environment control method - Google Patents

Description

  The present invention relates to a method for enabling communication between a plurality of systems each constituting a smart environment, which is a living space incorporating a function for providing information.

  In the future ubiquitous society, it is considered that many sensors, information devices, environments constructed by various networks, and smart environments are ubiquitous in various places. These smart environments are expected to be implemented with a variety of different devices, services, and architectures depending on where they are built.

  A smart environment is a living space (such as a living space or a public space) in which a function for providing information support is incorporated. For example, an office or home in which a personal computer, a printer, a communication device, and the like connected by a wireless LAN are a kind of smart environment. If you are in a smart environment, you can easily access a printer from a computer, but you may not be able to easily exchange any data with other offices or homes, that is, other smart environments. Absent.

JP 2006-302297 A Koichi Tanaka, Nobuo Kawaguchi, Nobuhiko Nishio "Design of heterogeneous smart environment connection by Secure Semantic Tunneling" Information Processing Society of Japan (13th Ubiquitous Computing System Research Group), 2006-UBI-12 (2006) Atsushi Nakano, Nobuhiko Nishio: PeerPool: Overlay network composed of DNS queries, Internet Conference 2007 (IC2007)

  When communicating with remote locations, commonly used functions include video / audio communication, PC screen sharing, file sharing, and collaborative editing. These already have services that implement each function and protocols that are specialized for the application. However, these services require unique knowledge and settings, and technical knowledge is indispensable for general users to use them. In addition, between different types of smart environments, there are problems such as connection of networks such as VPN, connection with different frameworks, and setting of network applications such as input of IP addresses.

  In response to such problems, the present invention makes it possible to simplify the preparation and procedure up to the use of existing services and smart environments as much as possible, and at this time, heterogeneous smart environment control that does not require major changes to existing networks. It aims to provide a method.

The present invention is a method for enabling communication between a plurality of systems each constituting a smart environment, which is a living space incorporating a function of providing information,
The plurality of systems include devices such as computers and printers,
The plurality of systems is a template that describes what service is used in an application, and at least a function that the application uses, a service that realizes the function, and an identifier of the protocol are defined in advance. With
One system sending a message to the other system;
The other system sends a reply including the function used by the application, the service realizing the function, and the identifier of the protocol to the one system;
The one system refers to the template and identifies a service available between the plurality of systems based on the reply;
The one system displaying the available services on a screen of the computer;
And the one system granting the other system access to the available service, the heterogeneous smart environment control method.

Granting access to the available services,
The one system issues a ticket in which access authority information including the content of a possible request, a use time limit, and identification information is written to the other system;
Attaching the ticket to a request for the service that the other system makes to the one system;
The one system examines the contents of the ticket attached to the request from the other system, and rejects the request when the request does not conform to the access authority information written in the ticket May be provided.

  In the embodiment of the present invention, a service recommendation / setting automation system (hereinafter referred to as “NUE system”) based on the concept of using services and protocols optimal for necessary functions and combining them is proposed. . The NUE system is a system including a mechanism for automating setting and control, a handler corresponding to a system application, and a mechanism for providing a user interface. NUE systems also use PeerPool to connect remote networks and instant messaging clients to communicate with remote NUE system users.

  The NUE system according to the embodiment of the present invention has a mechanism that can automatically execute a combination of different services and a mechanism that recommends services to users. In other words, the NUE system becomes a user interface for different services and protocols, and automates a series of settings and controls. In that case, in addition to using the service itself, PeerPool for connecting a remote smart environment network, an architecture that exposes a smart environment with different protocols as a web service by REST, to perform scalable privilege management for remote users Use "Ticket authentication method".

  The architecture and ticket authentication method disclosed as a Web service by PeerPool and REST will be described in detail later.

  FIG. 1 is an explanatory diagram of connection of different kinds of smart environments by the NUE system according to the embodiment of the invention. A smart environment is a living space (such as a living space or a public space) in which a function for providing information support is incorporated. For example, an office or home in which a personal computer, a printer, a communication device, and the like connected by a wireless LAN are a kind of smart environment. If you are in a smart environment, you can easily access a printer from a computer, but you may not be able to easily exchange any data with other offices or homes, that is, other smart environments. Absent.

1A and 1B are smart environments, and 2 is a communication network.
11A and 11B are service architectures. Here, the service architecture is a series of procedures for controlling devices and systems through a network. For example, UPnP, Bonjour, Jini, cogma, UnitedSpaces, etc.
12A and 12B are applications. Here, the application is a general existing software or system that is not supposed to be used in a smart environment. For example, video / audio communication, PC screen sharing, file sharing, collaborative editing work, etc.

13A and 13B are service architecture gateways. Here, the service architecture gateway is a mechanism having a client function of the service architecture, a function of publishing the service by REST, and a function of approving / permitting / restricting access to the service.
14A and 14B are network connections. Here, the network connection is a mechanism for connecting remote local area networks to each other and performing name resolution by DNS.
15A and 15B are translators. Here, a translator is a mechanism that translates and interconnects protocols between different service architectures and different applications.

Reference numerals 16A and 16B denote configuration mechanisms. Here, the configuration mechanism is a mechanism that automatically performs settings necessary for each of the above mechanisms to operate.
Reference numerals 17A and 17B denote management interfaces. Here, the management interface is a mechanism that provides a user interface that allows a user to control settings performed by the configuration mechanism.

  The NUE system proposed in this specification corresponds to the configuration mechanisms 16A and 16B and the management interfaces 17A and 17B in FIG. The configuration mechanisms 16A and 16B automate complicated settings by controlling each module. In addition, the management interfaces 17A and 17B perform necessary approval for security with respect to the automatic processing performed by the configuration mechanisms 16A and 16B. At the same time, recommend services that can be used.

  The services and applications handled by the configuration mechanisms 16A and 16B may already have protocols and service architectures specialized for various purposes. Here, remote communication is set as an application. However, in the protocol specialized for remote communication, H.323 for real-time voice and video communication, VNC (Virtual Network Computing) for sharing PC screens. RFB protocol to be used in. It must also be designed to handle protocols, service architectures, and applications that will become popular in the future.

Based on these facts, the following two were taken as the concept of the NUE system.
-Create an application by pasting different existing protocols without preparing an intermediate language.
-Appropriate services and protocols can be applied according to application requirements.

  Also, when connecting a remote smart environment, the service provider must be able to control the execution of services and applications appropriately. Connection of services and applications can be automated by the configuration mechanisms 16A and 16B, and the user is freed from complicated setting work and expertise, but since it is a connection with a remote place, it is not fully automated. It is required to be connected after confirmation between the parties.

Here, the remote conference is selected as a scene for performing communication with a remote place. The following functions are required to automate a series of tasks in a remote conference.
(1) User identification (identification of meeting partner)
(2) Presence exchange (confirm the status of the other party and call for start)
(3) Exchange of service information (services that can be used in each environment and service information such as protocol and IP address are mutually confirmed)
(4) Service presentation (notify the user of available services and confirm whether to use them)
(5) Network connection (to check the global address and to tunnel the network for services that require two-way communication)
(6) Service execution (execution of heterogeneous and remote services)

The result of investigating an actual remote conference about the above series of work is described.
In (1) and (2), a conference partner is specified and a call is made as to whether or not a conference is possible. This is often done by phone or instant messenger. If it can be confirmed that the other party can hold a meeting, then the communication method is confirmed in (3). For example, confirm that the video conference system is available, and communicate the IP address of the video conference system. (4) Then, tell the other party that you can use applications such as PC screen sharing, and confirm whether you want to use it. Furthermore, in (5), when using the application, if a network connection is necessary, the global address and VPN settings are made. Finally, in (6), the application is executed to share the PC screen and files with remote locations.

  As a mechanism for identifying users and exchanging presence, the NUE system uses a standard service and protocol specialized for its application, and is now used as an instant messenger (IM). Is used. Thereby, the user does not need to install special software.

  When starting communication with a remote location, the user specifies the conference partner by IM account (identification of the user). At this time, depending on the state of IM, the presence status can be confirmed. In addition, it is confirmed whether or not the conference can be started by actually transmitting a message (presence exchange). If you use IM, you can easily communicate with remote users.

  In order for the system to identify participating users and connected smart environments, the NUE system has the function of an IM client. When the meeting is started, the user invites the NUE system account to the above chat. In this way, the user does not have to input information such as the user participating in the remote conference and the connection destination to the system. Users can also interact with the NUE system through IM.

  The NUE system uses IM to communicate with a remote NUE system, confirms the service used with the remote location, and recommends the service to users at multiple locations. First, in the NUE system, what kind of service is used in the application is described. Based on this description (template), the NUE system selects the service to use. When the application is remote communication, the functions used are video exchange, voice exchange, screen sharing, document exchange, and so on.

  The template defines a function used by an application, whether the function is essential, an identifier of a service protocol that realizes the function, and a priority order.

  The NUE system compares the type of service written in the template with the type of service in the smart environment, and determines whether to recommend the service to the user. The service architecture gateways 13A and 13B publish the smart environment service to the outside as a REST service, but add the service type information to the Web Application Description Language (WADL) describing the REST service, and check whether the service is applicable to the template. Judging. REST and REST services will be described later. WADL is an abbreviation for Web Application Description Language, and is an XML specification for describing Web service specifications that conform to REST.

  The NUE system (1A or 1B in FIG. 1) then notifies the remote (other) NUE system of services available in its smart environment. By checking the services that can be used between NUE systems, it is possible to grasp which of the functions used in the application are actually available.

  In this way, when an application template is described and a different application, such as an application such as a presentation, is executed, a service is recommended to the user based on the presentation template.

  The NUE system recommends the picked up service to the user. Service recommendation to the user is information that is pushed from the system side to the user side, while the user needs to inform the system of the service to be used. For these series of interactive operations, the NUE system uses IM.

  The NUE system displays a recommendation message such as “A video conference system is available. The IM destination at this time is the user who invited the NUE system to the chat. This recommendation message is a URL to the Web server managed by the NUE system, and the user instructs the NUE system to use the service by clicking the link.

FIG. 2 is an explanatory diagram of the service recommendation sequence described above.
An application template is a setting file that describes a recommended service and a combination of services. The application template is a setting file that is referenced by the configuration mechanisms 16A and 16B in FIG.
A local Web server is a mechanism that provides an interface for interacting with a user. The local Web server corresponds to the management interfaces 17A and 17B in FIG.

  The service recommendation procedure will be described with reference to FIG.

First Step: The configuration mechanism 16A in FIG. 1 refers to the application template in FIG. 2 and grasps a service to be recommended to the user. The service architecture gateway 13A inquires whether the service is in the service architecture of its own site and matches the service. Also, whether there is a service that is not a service architecture is confirmed through a service handler.

Second step: The configuration mechanism 16A inquires about a service in the configuration mechanism 16B of the connection-destination smart environment B (one system sends a message to the other system). At this time, the configuration mechanism 16A describes the usable service in the description format of the application template and inquires of the configuration mechanism 16B. Based on the application template acquired from the configuration mechanism 16A, the configuration mechanism 16B confirms the services that can be used in the smart environment B (1B) and returns the same to the configuration mechanism 16A, as in the first step procedure. (Sends a reply containing the function used by the application, the service that implements the function and the protocol identifier).

Third step: The configuration mechanism 16A recommends available services to the user using the IM, which are found as a result of inquiring the smart environment A (1A) and the smart environment B (1B) (computer screen) The available services are displayed above). When there is a lot of information necessary for recommendation, the user interface is created by the local Web server 17A, and a link to the local Web server 17A is presented to the user.

Fourth step: The user grants the use permission of the recommended service to the configuration mechanism 16A through the user interface created by the IM or the local Web server (permits access to the usable service).

  The authorized local web server will take appropriate security measures to allow access to the service from a remote NUE system. In addition, available services are presented to the connected user.

  If the service to be published is based on the service architecture and there is no appropriate client software in the connected smart environment, the service is published as a RESTful web service. RESTful is a system implemented according to the principle of REST (Representational State Transfer). REST is a Web service system that uses XML and HTTP, with features such as stateless, CRUD using HTTP methods, URIs that can uniquely define resources, and the use of hypermedia. At this time, the NUE system creates a ticket that can be accessed only by the service permitted by the user. The NUE system sends, as service information, a URL for accessing the WADL describing the REST service and a ticket used to access the REST server to the remote NUE system. The service disclosure and authority management mechanism using REST will be described in detail later.

  If the service to be published is an existing network application and communication is possible by connecting to a private network, the NUE system uses the PeerPool function to tunnel the network between smart environments. In PeerPool, when publishing the host to the virtual network on PeerPool, register the DNS name to be disclosed by DNS query. The NUE system sends data such as key data necessary for PeerPool connection, registered DNS name, protocol, and port data to the remote NUE system. The network connection and host disclosure by PeerPool will be explained in detail later.

  The NUE system that has received the service information presents services that can be used to the user. As described above, the service published by REST does not have client software for executing the service on the remote site side. So, read the WADL and get how the service can be controlled. After that, an HTML page that displays a list of services and a control method (eg, “on” and “off”) is created and displayed to the user. When an arbitrary service is selected on the HTML page and controlled (for example, “on” or “off”), an XML message corresponding to the content is transmitted to the REST server, and the service is Executed.

When an existing network application is released, in the example of remote communication, processing such as connecting a video conference system or starting a VNC client is performed. In this case, the handler corresponding to the service type appropriately notifies the connection destination information to the client. The following notification methods are possible.
(1) Confirm service execution with IM or browser
(2) Display the URL by the protocol handler corresponding to the application on IM or browser
(3) Download connection information

  In the case of (1), the NUE system displays a message such as “The video conference system is available. Do you want to connect?” On the IM. This message is the URL to the Web server managed by the NUE system. When the user clicks the link, the corresponding service handler connects to the video conference system.

  In the case of (2), the NUE system displays the URL handler-name: // dns-name / corresponding to the application as a message on the IM. Here, "handler-name" is the protocol handler of the application, and "dnsname" is the virtual DNS name registered in PeerPool.

  In the case of (3), the NUE system enables the file storing the connection information to be downloaded from the local Web server and displays the URL as a message on the IM. For example, in the case of VNC, a file with the extension “vnc” is created. In this file, the DNS name registered in PeerPool is described as the connection destination address.

  In the NUE system according to the embodiment of the present invention, a user interface independent of the architecture of the smart environment is realized by using software generally installed in a client terminal. In addition, we were able to grasp the smart environment and service information and settings, and confirmed that network tunneling and service execution were possible automatically. In addition, the configuration mechanism automatically set each module according to the application template. By describing application templates, it is possible to deal with various applications. In the future, service architecture gateways may be implemented to accommodate new service architectures, and service handlers may be implemented to accommodate new network applications.

[Explanation of REST web service publishing]
First, Web services based on REST will be described. A web service is a software service that links with different software by exchanging messages using a web technology platform such as HTTP. REST (Representational State Transfer) is a style that uses the original HTTP model as a Web service interface (API) as it is, and has recently become mainstream as a simple method for building scalable distributed software. In REST, URLs are attached to all resources (addressability), and resource states can be expressed (html format, XML format, etc.). In addition, to obtain and change the status of the resource, a unified interface (HTTP GET, PUT, POST, DELETE method, etc.) is defined for the resource, and the status representation is transferred. By following REST principles, HTTP mechanisms (cache, proxy, keep-alive, load balancing, authentication, encryption, etc.) can be used effectively. In addition, since the server does not have the application state (statelessness), it has scalability against an increase in users.

  In the embodiment of the present invention, in order to absorb the difference between middleware developed independently in each smart environment, the REST server provided in each smart environment is provided with services (device functions, etc.) that exist in each smart environment. ) As a web service based on REST. The REST server corresponds to the service architecture gateways 13A and 13B in FIG. Client applications (REST clients) use these Web services to link different smart environments.

  Each service is treated as a resource and has a URL. Get the resource status by accessing the resource URL with the GET method, and update the status with the PUT method.

  Here, a ticket authentication method is adopted as an access authority management method that does not require user management. This method is inspired by a paper ticket used in an event or the like, and the access authority of the service is determined only by ticket information without specifying a user. For this reason, it is not necessary to separately manage users on the service providing side, and a scalable platform can be realized against the increase in users.

[Explanation of authority management mechanism by ticket authentication method]
In order to apply the ticket authentication method to the REST architecture, it is as follows. In this method, the service administrator issues data called “ticket” to the service user (guest user), and the service user attaches this ticket when making a request to the REST server.

  The ticket includes all the access authority information for the REST server, and the access authority can be determined only by the information included in the ticket. The access authority information is described in XML, the possible request contents (which HTTP method can be used for which URL), the expiration date of the ticket, the realm name that identifies the REST server (realm) to be authenticated, and the ticket The ID that identifies is included. (Other information may be added and used on the server side)

  A signature for preventing falsification is added to the ticket to prevent the service user from rewriting authority information. Prepare a private key for each realm (REST server), and add the calculated SHA1 digest to the data that combines the access authority information (body element) and the private key to prevent falsification. Sign.

  The service administrator gives a character string (ticket token) obtained by base64 encoding the signed ticket used by the application to the service user. When accessing multiple heterogeneous smart environments, connect tickets for multiple realms (create XML with the ticket element having multiple ticket elements as children) to form a single ticket token. You can also.

  The service user attaches this ticket token to the Authorization header when making an HTTP request to the Web server. To prevent eavesdropping on the ticket, when accessing the REST server with a ticket attached, the communication path is encrypted using SSL (Secure Socket Layer).

  The ticket authentication method is embedded as an extension to the Web server (REST server), and requests that do not match the access authority information written in the ticket are automatically rejected on the Web server side. In the ticket authentication method, there is no need to register guest user authentication information separately on the Web server. For this reason, there is no need to be particularly aware of the ticket authentication method when developing an application that runs on a Web server. In other words, if a ticket authentication method is used, it is possible to easily realize scalable and fine-grained access authority management for guest users when developing a Web service.

[Description of PeerPool network connection and host disclosure]
PeerPool is a known technology that connects only necessary devices between a plurality of smart environments using a DNS query as an interface (Non-Patent Document 2). PeerPool is a system that immediately controls and configures an IP layer overlay network (hereinafter referred to as Pool network) constructed between hosts called PoolGateway (hereinafter referred to as PoolGW) installed in each network using DNS queries as interfaces. PeerPool allows access control on a node-by-node basis, and selectively exposes nodes in the local network to the Pool network. It is not necessary to construct a pre-route between end hosts that is required for VPN.

  NAT is constructed in PoolGW for the host that is made public on the Peer network, and it becomes possible to access from the Pool network with a specific IP address. By specifying PoolGW as the next route to the address system used in the default route or Pool network, it is possible to access the public host via PoolGW from the local network that has Pool network PoolGW.

  Release to the Pool network is done by sending a name resolution DNS query for a specific type of host name to PoolGW, and the IP address added for the Pool network is returned as a response to the DNS query.

  PeerPool can easily perform all functions simply by specifying PoolGW as a default route or DNS server. However, there may be hosts that cannot even change these. On the other hand, by using PeerPool's virtual local node function, it can be used only by changing the DNS server. This DNS server change on each host can also be eliminated by performing packet forwarding on the existing DNS server and forwarding the DNS query to PeerGW once so that only the access from PeerGW is accepted by the existing DNS server. It is possible to use PeerPool from the entire local network without changing the existing host other than the DNS server. The outline at this time is shown in FIG. 3 correspond to the services A1, A2, B1, and B2 and the applications C, D, and E in FIG. 3 corresponds to the network connections 14A and 14B in FIG. Symbols A 'and B' in FIG. 3 are virtual addresses on the Pool Network and correspond to services and applications.

  A public IP address that has been converted to a virtual local node is assigned not only the IP address of the Pool network, but also the free IP address according to the local network IP address system. PoolGW publishes the corresponding IP address to the local network by holding the corresponding IP address as a virtual address, and PoolGW converts the IP address of the Pool network to the IP address of the Pool network using NAT. In effect, two-way NAT is performed by PoolGW et al.

  When a host called “newhostname. A group name.pool” published to the Pool network is made a virtual local node, it can be done by sending a name resolution DNS query for “newhostname.a group name.local.pool” to PoolGW. In response to the DNS query, the newly added IP address of the local network is returned. If it is not allowed or fails, name resolution will fail. If successful, using PoolGW as a DNS server allows access using the host name “newhostname.a group name.local.pool”.

  The realization of automatic tunnel network construction linked to service access using NUE and PeerPool is explained.

  If the above-mentioned PeerPool virtual local node is used for service disclosure by NUE, there is no need to change the target host side to secure the communication path, and it is possible to automatically construct tunnels between networks linked to service access . For example, by adding the name “vnc.some group.some smartspace.pool” to the VNC server and publishing it, you can use “vnc.some group. Some smartspace.local.pool ”can be used.

  The relationship between this “vnc.some group.some smartspace.local.pool” and the corresponding service is managed by the NUE, and the public host information is shared among the NUEs participating in the collaboration, creating a service-to-service collaboration. Sometimes used as the host name used by each service. This is handled in the same way as a normal host on each service and software, and a dynamic tunnel network can be constructed without being aware of it.

It is explanatory drawing of the connection of the different smart environment by the NUE system which concerns on embodiment of invention. It is explanatory drawing of the sequence of the service recommendation which concerns on embodiment of invention. It is explanatory drawing of the access by virtual local node-ization.

Explanation of symbols

1A, 1B Smart environment (system)
11A, 11B Service architecture 12A, 12B Application 13A, 13B Service architecture Gateway 14A, 14B Network connection 15A, 15B Translator 16A, 16B Configuration mechanism 17A, 17B Management interface 2 Communication network

Claims (2)

A method for enabling communication between a plurality of systems each constituting a smart environment, which is a living space incorporating a function for providing information,
The plurality of systems include devices such as computers and printers,
The plurality of systems is a template that describes what service is used in an application, and at least a function that the application uses, a service that realizes the function, and an identifier of the protocol are defined in advance. With
One system sending a message to the other system;
The other system sends a reply including the function used by the application, the service realizing the function, and the identifier of the protocol to the one system;
The one system refers to the template and identifies a service available between the plurality of systems based on the reply;
The one system displaying the available services on a screen of the computer;
A heterogeneous smart environment control method comprising: the one system granting the other system access to the available service. Granting access to the available services,
The one system issues a ticket in which access authority information including the content of a possible request, a use time limit, and identification information is written to the other system;
Attaching the ticket to a request for the service that the other system makes to the one system;
The one system examines the contents of the ticket attached to the request from the other system, and rejects the request when the request does not conform to the access authority information written in the ticket The heterogeneous smart environment control method according to claim 1, further comprising:

Images