US20090092109A1

US20090092109A1 - Method and Apparatus for Enabling Discovery Within a Home Network

Info

Publication number: US20090092109A1
Application number: US12/097,625
Authority: US
Inventors: Torbjorn Cagenius; Ayodele Damola
Original assignee: Individual
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2005-12-19
Filing date: 2005-12-19
Publication date: 2009-04-09
Also published as: US20080310435A1; CN104717315A; CN101341716A; EP1964351A1; CN104717315B; WO2007071282A1; WO2007071461A1; CN101361342A; US8289980B2

Abstract

A method and Home IP Multimedia Subsystem (IMS) Gateway for enabling a non-IMS enabled device within a home network to discover the availability of the Home IMS Gateway. The Home IMS Gateway is interposed at a control plane between a remote network and the non-IMS enabled device. The Home IMS Gateway sends an advertisement message to the non-IMS enabled device advertising the availability of services on the remote network via the Home IMS Gateway.

Description

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for enabling discovery within a home network, and in particular to enabling the discovery of a Home IP Multimedia Subsystem Gateway by a non-IP Multimedia Subsystem enabled device.

BACKGROUND TO THE INVENTION

IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the numbers of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services, which are considered in more detail below.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over 3G mobile communication networks (3GPP TS 23.228 and TS 24.229 Release 5 and Release 6). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and web servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP), Message Session Relay Protocol (MSRP), Hyper Text Transfer Protocol (HTTP).
IMS requires an access network which would typically be a 2G/3G General Packet Radio Service (GPRS)/Packet Switched (PS) network, but which might be some other access network such as fixed broadband or WiFi.
The TISPAN working group of the European Telecommunications Standards Institute (ETSI) is currently working on a proposal for the Next Generation Network (NGN) for fixed networks based upon IMS. As part of this project, consideration will be given to a so-called IMS Residential Gateway (IRG), which will allow non-IMS terminals to access IMS services. It is expected that the IRG will find applications in the home and small office environments where users might wish to access IMS services using a number of non-IMS enabled terminals, which may or may not be SIP terminals. Examples of non-IMS but SIP enabled terminals are SIP telephones and PCs, whilst examples of non-IMS terminals that do not have SIP functionality are legacy telephones including DECT telephones and IP devices with UPnP (Universal Plug and Play) support such as STBs (Set top boxes). The IRG will include a SIP gateway in order to handle interoperability issues (e.g. conversion between SIP and other signalling protocols required by user equipment). Of course, alternatives to the TISPAN IRG proposal may well emerge in the future.

SUMMARY OF THE INVENTION

At present, a plain IP device on a home network that is not IMS enabled cannot automatically discover the IRG or the functions of the IRG. As the IRG provides means for translating between IMS protocols and protocols used by the non-IMS enabled device, it is therefore difficult for non-IMS enabled devices to access remote networks having, for example, IMS services. For example, it is not possible to initiate an outgoing IMS call from a non-IMS enabled IP device if the non-IMS enabled device cannot discover the IRG, as the non-IMS enabled device is not aware of the availability of the remote network.
According to a first aspect of the present invention there is provided a method of automating the process for a non-IMS enabled device to detect the availability of a Home IMS Gateway, the method comprising:

- interposing a Home IMS Gateway at a control plane between a remote network and one or more non-IMS enabled devices;
- sending an advertisement message to the or each non-IMS enabled device, said advertisement message advertising the availability via the Home IMS Gateway of services on the remote network.

Preferably, a service or a device on said remote network is a Session Initiation Protocol service or device.
It is preferred that a service or a device on said remote network is an IMS service or device.
A common standard for interoperability in home networks is Universal Plug and Play (UPnP). The UPnP standard is based on all devices on a home LAN being connected to the same IP sub-net, and so all devices have IP capability and receive local IP addresses from the Dynamic Host Configuration Protocol (DHCP) server in the residential gateway. For this reason, it is preferred that the advertisement message uses Universal Plug and Play protocol.
Preferably, the method further comprises sending said advertisement message periodically over a Local Area Network.
The method may further comprise:

- storing at least one address at a database on a Local Area Network, said address corresponding to a Uniform Resource Identifier identifying an IMS device or service;
- sending said address to said non-IMS enabled device.

Preferably, the database is disposed at the Home IMS Gateway.
In a specific embodiment, the method further comprises the step of registering the advertisement message at the or each non-IMS device.
According to a second aspect, there is provided an IMS Service Gateway comprising:

- a first interface for communicating with a remote network;
- a second interface for communicating with a non-IMS enabled device;
- means for sending an advertisement message to the non-IMS enabled device, the advertisement message advertising the availability via a Home IMS Gateway of services on the remote network.

According to a third aspect, there is provided a method for alerting a non-IP Multimedia Subsystem device to the availability of an IMS network, the method comprising:

- providing means to automatically advertise to the non-IMS device the availability of devices or services via a Home IMS Gateway on the IP Multimedia Subsystem network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a Home IMS Gateway comprising an IMS Service Gateway within a home network;

FIG. 2 illustrates services and actions of an IMS Service Gateway device; and

FIG. 3 illustrates signalling to establish a call session using an IMS Service Gateway device.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Referring to FIG. 1 herein, there is illustrated schematically a Home IMS Gateway (HIGA) 101 comprising an IMS Service Gateway (ISG) 102 both within a Local Area Network (LAN). The HIGA 101 functions as an IRG, in addition to providing other functions. The HIGA 101 is disposed on a control plane in the LAN. Non-IMS devices 103, 104 are also connected to the LAN. These devices are plain IP or SIP devices, such as a PC or a STB, and so cannot by themselves establish media connections with remote SIP or IMS clients. These non-IMS enabled devices are UPnP devices.
The HIGA 101 contains a range of functions to assist inter-working between IMS and non-IMS enabled devices 103, 104 on the LAN. The HIGA 101 may be implemented in a separate physical box or integrated in any other box in the home, e.g. the Residential Gateway (RGW) 105 or a STB. The ISG 102 is also part of the HIGA 101 and is preferably implemented in the same physical box as the HIGA 101. The ISG 102 uses the UPnP protocol to communicate with other devices on the LAN. The HIGA also contains an IMS Address Book (IAB) 106 to facilitate communication between non-IMS enabled devices on the LAN and remote IMS services.
The UPnP ISG device 102 advertises its presence on the LAN by sending a discovery advertisement message: Device available—NOTIFY with ssdp:alive. The message is sent as a multicast over User Datagram Protocol (UDP) to a standard address and port. Control points within the devices on the LAN listen to this port to detect when new capabilities are available on the LAN. To advertise the full extent of its capabilities, the ISG device 102 multicasts a number of discovery messages corresponding to the services available. The UPnP ISG advertises the remote SIP and IMS services and this is registered by the UPnP Control Points of the LAN devices 103, 104.
The UPnP description for the ISG device 102 is partitioned into two parts; the device description describes properties of the HIGA, while the service description describes the services available via the HIGA. The device description lists basic properties of the HIGA as well as all services it supports.
The UPnP ISG device 102 is a logical entity that advertises a set of communication services to non-IMS enabled UPnP devices 103, 104 on the LAN. The UPnP ISG device 102 introduces the IMS and SIP services. Each of these services allows non-IMS enabled UPnP devices to establish media connections with remote SIP or IMS clients by invoking the relevant UPnP actions in the ISG 102. Referring to FIG. 2 herein, there are illustrated services and actions advertised by an IMS Service Gateway device. These are provided by way of example, and it will be appreciated that other actions are possible.

Call Action

The call action 201 enables a non-IMS enabled device on the LAN to establish a conference call with a remote IMS client. The call may be voice, video or both depending on the functionalities of the RTP client of the non-IMS enabled device. The Call action has the following syntax:
Call([contact] [parameters])
Contact: SIP address or IMS Public Identity in form of a SIP URI of the callee.
Parameters: these represent parameters that are provided by the RTP client such as the codec, format etc. These are preference values passed by the client application. This field is optional.

Hang_Up Action

The hang up action 202 is invoked by the UPnP Control Point of a non-IMS enabled UPnP device on the LAN to end an ongoing media session. The hang up action has the following syntax:
Hang_up(contact, session_ID)
Contact: the SIP URI or IMS public identity of the callee.
Session_ID: A string variable containing a unique identifier of a connection established between the HIGA and the remote client.

Access_Content Action

The access content action 203 enables a non-IMS enabled UPnP device on the LAN to access multimedia content stored in the remote IMS system. The access content action has the following syntax:
Access_Content([server],[parameters])
Server: the SIP URI or IMS public identity of the server where the content is located.
Parameters: these represent optional parameters that may be provided by the RTP client such as the codec, format etc.

GetAddrBk Action

An IMS address book (IAB) 106 function, shown in FIG. 1 as part of the HIGA 101, stores all outgoing and incoming IMS Public Identities. The IAB can be common to all users of the LAN or separate users of the LAN may have their own IAB for increased privacy. This function facilitates simplified IMS service activation from non-IMS enabled UPnP devices 103, 104 on the LAN.
To establish a video or audio session with a remote client connected to the IMS system, the UPnP Control Point of the non-IMS enabled UPnP device 103 on the LAN invokes the GetAddrBk action 204 specifying the user's name. The HIGA 101 returns a list of SIP URIs and their respective display names as stored in the IAB 106. The user is able to select a desired contact URI and invokes the Call action of the IMS or SIP service of the UPnP ISG device 102. This effectively provides a “speed dial” type of functionality. Alternatively the user would have to input the SIP URI into the home device when making a call. The HIGA 101 also stores the SDP of each device on the home network, hence the SDP is the default information used for session negotiation.
The GetAddrBk action 204 has the following syntax:
GetAddrBk([user_name])
User_name: Identity of user that sends the request (this parameter is optional).

Modified Media Renderer

Existing UPnP architecture assumes that media is transported via HTTP, IEEE 1394 or the RTSP protocol. The RTSP protocol supports RTP, which is the protocol used to transport media between IMS clients and hence is of interest. Using RTSP, the UDP port numbers of the source and sink RTP applications for a given media session are made known to the opposite parties by RTSP. The handshake is exchanged within the RTSP SETUP and OK messages. To be able to explicitly exchange the UDP port numbers allocated for a given media session between a UPnP Media Renderer in a device on the LAN and a remote IMS device, a new UPnP action is deemed necessary. The new UPnP action is included in the AVTransport service. This method returns the IP address of the non-IMS enabled UPnP device on the LAN and the UDP port on which the non-IMS enabled UPnP devices on the LAN is ready to receive RTP media. The syntax of the action is as follows:
IP,port Set_com_transport(IP′, port′, ID)
IP: IP address of the non-IMS enabled UPnP device on the LAN
IP′: IP address of the remote IMS device
Port: Port number on which the non-IMS enabled UPnP device on the LAN is ready to receive RTP
Port′: Port number on which the remote IMS device is ready to receive RTP
ID: unique identifier of the session which is assigned by the HIGA
Alternatively, this action can be implemented within a new UPnP service. This approach reflects the changes that can be made on the UPnP Media Renderer side and is depicted as a dotted box 107 in the non-IMS enabled UPnP IP device in FIG. 1.
RTP/UDP is used as an example of transport protocol throughout this description.

SIP/IMS Communication

Combined, the IMS and SIP services of the UPnP ISG device offer communication services to non-IMS enabled UPnP devices via the call action of the ISG device. The non-IMS enabled UPnP device is running a UPnP Media Renderer device, which relies on an underlying RTP stack to render RTP media. An alternative embodiment is a non-IMS enabled UPnP device running a RTP application that is exposed to UPnP network via a UPnP bridge.
The establishment of a call between a non-IMS enabled UPnP device and a remote IMS device entails the negotiation of media codecs, UDP ports for RTP and the opening of these ports in the RGW. The HIGA terminates the SIP signalling originating from the remote IMS terminal and performs all negotiations with the non-IMS enabled UPnP device via UPnP. The media port in the non-IMS enabled UPnP device may or may not be of a predefined value. If the media port is predefined, this value is stored in a device database 109 in HIGA 101. Alternatively, the media ports are dynamic in nature and are allocated for a given connection during the connection establishment. For this reason it is deemed necessary to introduce a new action into the AVTransport service of the UPnP Media Renderer device, as described above for a modified media renderer. This action informs the Media Renderer device of the IP and port number of the originating RTP media. The device responds indicating the number of the UDP port which was opened for the connection. Alternatively, a new service can be defined for the UPnP Media Renderer device, which addresses all two-way RTP communication issues for Media Renderer devices.
Referring to FIG. 3 herein, there is illustrated the signalling to establish a call session using an IMS Service Gateway device. The signalling illustrated is by way of example only, as different signalling may be used to establish a call session.
A precondition 301 for the access to IMS services by a non-IMS enabled UPnP device is that the non-IMS enabled UPnP device is registered to the HIGA and the HIGA is itself registered to the IMS core. To establish a video or audio session with a remote IMS device, the UPnP Control Point of the non-IMS enabled UPnP device invokes the Call action with the SIP URI as the first parameter. Prior to this the GetAddrBk action may have been invoked to get the list of SIP URI. The second parameter of the Call action allows specification of connection parameters of the session such as the codec, media formats etc. If these are not specified, the HIGA uses the session definition parameters as defined by the SDP of the device stored in the device database.
The Call action initiates 302 the selection and reservation of a port on the WAN interface of the RGW through the UPnP IGD. The selection of a free port number is achieved by invoking the GetGenericPortMappings action with an incrementing array index until no more entries are found on the UPnP IGD, hence a list of all current NAT bindings is returned. The HIGA logic is then able to select a free port based on this list. After this a preliminary port binding is made in the RGW. This NAT binding is redefined and is made at this stage with the aim of reserving the selected port number. The port number is used along with the external IP address of the RGW in the SDP body of the INVITE message as the media port for the respective RTP stream.
The INVITE message 303 passes via several nodes of the IMS core, and is received by the remote IMS device of the callee. The OK message 304 contains the SDP which includes the IP address of the terminal and the UDP port for incoming RTP streams. On reaching the HIGA device, the SDP of the OK message is parsed and the IP address and port are extracted. The HIGA CP invokes the proposed Set_com_transport( ) action in the Media Renderer device which informs the RTP stack of port number and IP address of incoming RTP media. The action returns the port number opened by the RTP stack of the Media Renderer device. The HIGA then creates a NAT binding using the earlier selected port in the RGW for RTP media using the Addportmapping action 305 based on the following information: the IP address of the IMS terminal, the external port of the RGW for incoming RTP, the IP address of the calling home device and its port number.
In the event of a problem opening ports in the RGW, the ACK message sent in has a different port value and hence causes a re-negotiation of connection between the HIGA and the remote IMS device. The call establishment procedure is successful up to the point of Addportmapping 305, the HIGA sends an ACK message to the IMS terminal and from this point the caller and callee may start exchanging RTP traffic.
The Access_content action differs from the call action in that the SIP URI of a server is specified and most likely the RTP flow is uni-directional, from the server to the home device.
To terminate the call, the non-IMS enabled UPnP device uses the Hang_up action function 306 of the IMS service to end the media session. The parameter of the action is the SIP URI of the callee and the session ID. When the ISG device receives a Hang_up message a SIP BYE message is sent to the remote IMS device informing it of the session end. The NAT binding is also removed in the IGD by invoking the DeletePortMapping 307.
UPnP enabled SIP and IP devices on the home LAN automatically receive information on the presence and capabilities of a home IMS gateway. This information can be used to initiate IMS calls or services from non-IMS devices within the home network. One of the supporting capabilities of HIGA is the IMS Address Book, which can be used by home devices to facilitate easier access to IMS services.
It will be apparent to one skilled in the art that various modifications may be made to the embodiments described above without departing from the scope of the present invention. For example, the ISG is described as being implemented with the HIGA, although it is possible to dispose an ISG at other points in the LAN and not necessarily with the HIGA.

Claims

1. A method of enabling a device that is not IP Multimedia Subsystem (IMS) enabled to detect the availability of a Home IMS Gateway, the method comprising the steps of:

interposing a Home IMS Gateway at a control plane between a remote network and the non-IMS enabled device; and

sending an advertisement message to the non-IMS enabled device, said advertisement message advertising the availability via the Home IMS Gateway of services on the remote network.

2. The method according to claim 1 wherein a service on said remote network is a Session Initiation Protocol service.

3. The method according to claim 1 wherein a service on said remote network is an IMS service.

4. The method according to claim 1 wherein said advertisement message uses Universal Plug and Play protocol.

5. The method according to claim 1, wherein the step of sending the advertising message includes sending said advertisement message periodically over a Local Area Network.

6. The method according to claim 1 further comprising the steps of:

storing at least one address at a database on a Local Area Network, said address corresponding to a Uniform Resource Identifier identifying an IMS device or service; and

sending said address to said non-IMS enabled device.

7. The method according to claim 6 wherein the database is disposed at the Home IMS Gateway.

8. The method according to claim 1 further comprising the step of registering the advertisement message at the non-IMS enabled device.

9. A Home IP Multimedia Subsystem (IMS) Gateway comprising:

a first interface for communicating with a remote network;

a second interface for communicating with a non-IMS enabled device; and

means for sending an advertisement message to the non-IMS enabled device, the advertisement message advertising the availability via the Home IMS Gateway of services on the remote network.

10. A method for alerting a device that is not IP Multimedia Subsystem (IMS) enabled to the availability of an IMS network, the method comprising:

automatically advertising to the non-IMS device, the availability of devices or services via a Home IMS Gateway on the IMS network.