Techniques have been developed for communication of media and services in a local network with devices using internal addressing and transport means, which can also be referred to as a private or home network, a LAN (Local Area Network), a residential or office network. In this description, the term “local network” is used to represent any such networks, and the term “device” represents any communication entity capable of providing services in the local network. The devices in a local network may include any types of entities in which services are configured and managed, such as telephones, computers, application servers, web servers, and various devices related to home surveillance, home automation and health care.
UPnP (Universal Plug-and-Play) is a technology for establishing standardised device protocols for communication in a local network between different devices that may use different access technologies, operating systems, programming languages, format standards and communication protocols. UPnP supports a process called “discovery” in which a device can join a local network and exchange capabilities and share services with other devices in the network. The media and services available in the local network are typically “exposed”, i.e. presented through a suitable interface, to the local devices by means of a web server or the like. A local network typically also has a gateway function for enabling external communication for devices in the local network. This gateway is often called “RGW” (Residential Gateway) or “HG” (Home Gateway), the latter being used by the standard organisation HGI (Home gateway Initiative).
A network architecture called IMS (IP Multimedia Subsystem) has been developed as a platform for handling and controlling multimedia services and sessions. In order to provide IMS-based services for devices in a limited local network and to enable multimedia communication with entities outside the local network, a gateway commonly called “HIGA” (Home IMS Gateway) has been devised as a solution where an external IMS core is used for establishing sessions with external entities.
UPnP also defines a mechanism for remote access, enabling a remote UPnP device located outside the local network to communicate with UPnP devices located within the local network. In FIG. 1, a local network 100 comprises various different devices D1-D4 in a family residence or an office, also employing gateway functions for external communication, in this case including a HIGA 100a and an RGW 100b, the latter typically having a NAT (Network Address Translation) function and a local DHCP (Dynamic Host Configuration Protocol) server for managing local IP addresses of the devices which are valid only locally within the network 100, as is well-known in the art. In practice, the HIGA 100a may be physically integrated in the RGW 100b to form a gateway node.
FIG. 1 also illustrates an opposite local network 102 which has a similar structure and entities as network 100, although not shown in detail here. UPnP also enables a user of a device D5 in network 102 to remotely access media and services from a device in network 100 as follows. The HIGA 100a is involved in IMS signalling with a corresponding HIGA or an IMS-enabled device in network 102 over an IMS core 104, as shown by an action 1.1, in order to establish a connection for communication between the two local networks 100, 102. Typically, a VPN (Virtual Private Network) tunnel is setup as a connection between RGW 100b and a corresponding entity in network 102, as shown by an action 1:2.
The above HIGA or RGW may be used as a web server for exposing available media and services to both devices in network 100 and remote devices in network 102. Thereby, the user of device D5 in network 102 is able to browse for media and services locally configured in network 100, e.g. in device D4, over the established VPN tunnel, as shown by an action 1:3. If some service in device D4 is selected by the browsing user in network 102, a session over the RGW 100b for service usage is executed, as shown by an action 1:4.
The known solutions for remote access, including the one described above, thus require that a point-to-point connection is established between the two local networks, typically a VPN tunnel, before a remote user is able to browse and find out what media and services are available in the opposite local network. This laborious procedure must actually be performed each and every time a user wants to search for remote services, even if no service is actually selected and used. It becomes an even greater burden when the user wants to see available services in more than one local network, e.g. in the residences of various friends, associates and connections, also involving considerable amounts of signalling that consume network and processing resources.
Another restriction is that the current solutions for remote access to a local network offer access control chiefly depending on the accessing device, such that either all or nothing of the media and services in a local network is shown to a browsing remote device. As a result, the entire selection of services in a home must be shared with others, if at all, and selective sharing of only some services is thus not enabled in current solutions unless access rules or the like are configured in the local network specifically for each remote user which is a rather complex procedure.
Further, when establishing a connection between devices in two opposite local networks, the risk of collision between local network addresses arises when potentially overlapping private address spaces are used within the networks. There is typically no coordination of address allocation between different local networks, which is commonly handled independently by DHCP servers in the respective networks. So this problem of overlapping address spaces must also be solved to enable the above browsing procedure.