Patent Application
20090080453
The present invention relates generally to Universal Plug and Play (UPnP) networking. More particularly, the present invention relates to triggering Internet Protocol version 6 (IPv6) connectivity between a remote and home network.
This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
UPnP technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and personal computer devices of all types. UPnP is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technology provides a distributed, open networking architecture that leverages Transmission Control Protocol/Internet Protocol (TCP/IP) and Web technologies in order to enable seamless proximity networking, in addition to control and data transfer among networked devices.
The UPnP Device Architecture (UDA) is designed to support zero-configuration, “invisible” networking and automatic discovery for a breadth of device categories from a wide range of vendors. In other words, the UDA enables a device to be capable of dynamically joining a network, obtaining an IP address, conveying the device's capabilities, and learning about the presence and capabilities of other devices. UPnP Remote Access provides an environment that allows a remote UPnP device to connect to a home UPnP network and interact with UPnP devices or entities connected to that home UPnP network, where the UPnP remote device should theoretically have the same experience as if it were in the home UPnP network. Hence, if IPv6 devices are available in the home network and the remote device is IPv6 capable, the remote device is to be able to interact with the home IPv6 devices.
However, the UDA was initially designed to support Internet Protocol version 4 (IPv4)-only connectivity, where subsequent updates (e.g., v1.0.1 and v1.1) have added IPv6 support. However, IPv6 is not yet widely used and the UDA does not mandate the use of IPv6-only devices.
Various embodiments comprise a method, computer program product, and an apparatus for establishing an as-needed IPv6 channel between a remote network and a home network. Local discovery messages are monitored at the home network. In these embodiments, it is determined whether at least one of the local discovery messages is transmitted by a UPnP device of the remote network utilizing IPv6 connectivity. Additionally, it is determined whether a need exists to establish an additional as-needed IPv6 channel. Once it is determined that an additional as-needed IPv6 channel is required, the as-needed IPv6 channel is activated.
Other embodiments comprise a method, computer program product, and apparatus for providing IPv6 support for transport agent capability. Context information indicative of at least one UPnP device in a remote network is received. Furthermore, in these embodiments, a remote access server transport agent associated with a home network is configured by indicating IPv6 capability. Additionally, a remote access client transport agent associated with a remote network is also configured, thus providing an as-needed IPv6 channel between the remote network and the home network.
Various embodiments described herein can reduce overhead relative to current remote access utilizing IPv4-only connectivity. Therefore, improved battery performance for a mobile device can be achieved because an IPv6 connection is activated only as needed, which can be particularly beneficial since many devices currently available and likely to be available in the near future will not possess IPv6 connectivity, meaning that implementing IPv6 “always on” connectivity would simply waste battery life. Additionally, various embodiments are scalable in the sense that remote access can be provided for both IPv4 and IPv6 connectivity-based UPnP devices.
These and other advantages and features of the invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.
Various embodiments provide a mechanism for using the Remote Access Discovery Agent (RADA) synchronization function of a remote access architecture to signal when UPnP IPv6 devices become available. Furthermore, various embodiments can trigger the establishment of a IPv6 channel between a remote network and a home network, thus activating IPv6 connectivity for the remote UPnP IPv6 devices in the home network.
The remote access architecture utilizes discovery agents to exchange discovery information from one network to another network, thereby bridging the networks in a RADA synchronization process. Each discovery agent has at least three components, e.g., a listener, a sync, and a relay. The listener is a logical support function of the RADA and can comprise a generic control point that constantly monitors the local network in order to detect which devices are joining or leaving the local network. Alternatively and/or additionally, the listener can monitor local multicast eventing and inform the RADA when multicast events are received.
The sync can refer to a Simple Object Access Protocol (SOAP)-based protocol that helps the discovery agent of a local network push local discovery information to a RADA. More particularly, the sync process comprises closely-connected service and control point functionality, where the control point functionality is utilized to push the local discovery information to a remote network, as described above, and the service functionality is utilized to receive the local discovery information from a remote network. Additionally, the sync process can be performed by two discovery agents that have associations between a local control point and a remote service, as well as between a remote control point and a local service. In other words, the sync process can be thought of as being symmetrical because two discovery agents are synchronizing each other by pushing or exchanging local discovery information to their respective remote ends.
The relay is another logical support function of the RADA and can be a component that recreates original discovery information (e.g., discover information collected by a remote listener and pushed via a sync process) and distributes it within the local network. Additionally, for each device in a remote synchronization tree of the RADA, periodic SSDP announcements can be sent onto the local network indicating that the device is alive. If a device is removed from the remote synchronization tree, the relay can send an SSDP expiration announcement onto the local network.
The UDA mandates IPv4 connectivity for all UPnP devices. However, as described above, the UDA allows for UPnP devices that can support IPv6 connectivity. It should be noted that the IPv6 “roll-out” will increase the number of devices capable of IPv6 connectivity. However, many UPnP devices do not currently have IPv6 connectivity, nor will many UPnP devices have such connectivity in the near future. Thus it is expensive to maintain both IPv4 and IPv6 connectivity to a home network unless UPnP IPv6 devices are actually present in the home network.
Because the listener component of a discovery agent listens for/monitors the local discovery messages, it is able to detect when devices join the UPnP network. Moreover, the listener component can determine whether the devices joining the UPnP network are IPv4 or IPv6-capable. The specific information about the addressing mechanism used can be found in the HOST header of SSDP packets. SSDP packets are the basis of the UPnP discovery protocol, where devices that join a UPnP network advertise services to one or more control points, and control points that join a UPnP network are allowed to search for devices of interest on the UPnP network. Therefore, discovery messages are exchanged between devices and control points, where the discovery messages contain, e.g., essential specifics regarding the device, the control point's available services, etc.
For example, as shown below, a SSDP message indicates that the HOST header contains an address 239.255.255.250. In this instance, it can be determined that the UPnP device that generated this particular SSDP message utilizes IPv4 connectivity.
In the following SSDP message, the HOST header contains an address value of [FF02::C]. This value can, for example, indicate that the UPnP device that generated this SSDP message utilizes IPv6 connectivity.
Based on this information regarding the type of UPnP device that generated the SSDP message, the discovery agent can mark those UPnP devices that are dual stack (e.g., a second UPnP Device 240 illustrated in
As described above, the listener component of the RADA 200 can detect when devices join or leave a network and send notifications of such joining or leaving to the RADA 200. Therefore, the RADA 200 can maintain an up-to-date image of the local UPnP network, e.g., block 210 which is representative of the local network image. As also shown in
A secure transport channel is configured in addition to having the context information about the presence of UPnP IPv6 devices in a remote network in order to allow interaction with the devices. To accomplish this configuration of the secure transport channel, a transport agent is configured via a configuration interface, e.g., RATAConfig, on a Remote Access Server (RAS). It should be noted that the RAS can provide access to the home network from a remote location where a remote device is located, e.g., a residential router, a personal computer, a third party dedicated device, etc. The transport agent IPv6 capability is marked as being present in the transport agent capability. As shown in the syntax below, the IPv6 attribute of the transportAgentCapability is indicated to be “true.”
The transport agent on the Remote Access Client (RAC) is also configured via a RATAConfig interface at the RAC. It should be noted that the RAC is a peer device that need not be a part of the physical home network to which remote access is desired. When both transport agents at the RAS and the RAC are configured, the discovery agent is able to activate the IPv6 connection by changing the connected flag in the SystemInfo state variable. This is shown in the syntax below, where connected flag is given a value of “true.”
<?xml version=“1.0” encoding=“UTF-8”?>
<RADA xmlns=“urn:schemas-upnp-org:ra:rada”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“urn:schemas-upnp-org:ra:rada
http://www.upnp.org/schemas/ra/rada-v0.10-20061201.xsd”>
<systemInfo
As described above, IPv6 connectivity according to various embodiments can be effectuated on an as-needed basis. Therefore, IPv6 channels which have been configured and activated in accordance with various embodiments can also be torn down when UPnP devices with IPv6 connectivity are, e.g., no longer present in the remote network. That is, if the listener component of the RADA, for example, monitors SSDP messages and it is determined that no such messages are being received by UPnP devices having IPv6 connectivity, a trigger is set off indicating that no “motives” exist to maintain the IPv6 channel/connection. Therefore, at least a similar process or processes to that utilized for activating an IPv6 connection can be used, e.g., in reverse or alternatively to tear down the IPv6 connection. In other words, UPnP devices having IPv6 connectivity can be removed from a remote tree using, in part, the sync process, e.g., via a RADASync::RemoveRemoteDevice action, where the remote tree can be likened to the local network image 210 illustrated in
Various embodiments described herein provide a “lightweight solution,” where overhead compared with current remote access utilizing IPv4-only is very small. Furthermore, improved battery performance for a mobile device can be achieved because as described herein, an IPv6 connection is activated only as needed. Additionally, the various embodiments are scalable in the sense that remote access can be provided for both IPv4 and IPv6 connectivity-based UPnP devices.
It should be noted that the system 100 in which the present invention can be utilized, comprising multiple communication devices that can communicate through a network. The system 100 may comprise any combination of wired or wireless networks including, but not limited to, a mobile telephone network, a wireless Local Area Network (LAN), a Bluetooth personal area network, an Ethernet LAN, a token ring LAN, a wide area network, the Internet, etc. The system 100 may include both wired and wireless communication devices.
For exemplification, connectivity in the system 100 shown in
The exemplary communication devices of the system 100 may include, but are not limited to, a mobile device, a combination PDA and mobile telephone, a PDA, an integrated messaging device (IMD), a desktop computer, and a notebook computer. The communication devices may be stationary or mobile as when carried by an individual who is moving. The communication devices may also be located in a mode of transportation including, but not limited to, an automobile, a truck, a taxi, a bus, a boat, an airplane, a bicycle, a motorcycle, etc. Some or all of the communication devices may send and receive calls and messages and communicate with service providers through a wireless connection to a base station. The base station may be connected to a network server that allows communication between the mobile telephone network and the Internet. The system 100 may include additional communication devices and communication devices of different types.
The communication devices may communicate using various transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, etc. A communication device may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.
The present invention is described in the general context of method steps, which may be implemented in one embodiment by a program product including computer-executable instructions, such as program code, executed by computers in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Software and web implementations of various embodiments could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps. It should also be noted that the words “component” and “module,” as used herein and in the claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.
The foregoing description of various embodiments have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the present invention. The embodiments were chosen and described in order to explain the principles of the present invention and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated.
