Patent Application
20120128006
The invention relates generally to a method and arrangement for enabling multimedia services in an external network for a device in a local network.
A multitude of different types of communication terminals or devices have been developed for packet-based multimedia communication using IP (Internet Protocol). Multimedia services typically involve transmission of media in different formats and combinations over IP networks. An architecture called “IP Multimedia Subsystem” (IMS) has also been developed by the 3rd Generation Partnership Project (3GPP) to enable such multimedia services and sessions for user terminals connected to different access networks. The signalling protocol “SIP” (Session Initiation Protocol) is typically used for IMS services, as controlled by specific session control nodes in the IMS network.
3GPP has further defined various solutions and mechanisms for the next generation multimedia telephony, known as “MMTel” for short. In order to access an IMS network and its services, it is required that the terminal used is “IMS-enabled” and “MMTel compliant”, i.e. capable of registering and communicating with the IMS network according to prescribed procedures and protocols. However, terminals offered today by many vendors in the Consumer Electronic (CE) industry are actually neither IMS-enabled nor MMTel compliant as required.
Techniques are also being developed for multimedia communication involving devices in a limited local network using internal addressing and transport means, also referred to as a residential or office network, LAN (Local Area Network), private or home network. In this description, the term “local network” represents any such networks, and the term “local device” represents any entity capable of media communication inside a local network. Further, any networks outside the local network are referred to as “external networks”.
The local devices may include any types of entities capable of communication within the network, such as fixed and wireless telephones, computers, media players, game units, servers and television boxes, the latter also called “STB” (Set Top Box). As indicated above, a great number of these devices are not IMS-enabled even though they may be configured to use SIP as such, typically according to IETF (Internet Engineering Task Force). Furthermore, other devices occurring in local networks may not even be capable of using SIP, e.g. older so-called “legacy” telephones, PC's and STB's.
The large amount of such non-IMS devices occurring in local networks makes it desirable to provide for an inter-working solution between non-IMS devices and IMS networks, to enhance the market for multimedia services. Therefore, a gateway called “HIGA” (Home IMS Gateway), has been devised as an interface between a local network and an IMS network. The HIGA handles authentication towards the IMS network on behalf of local devices, and translates between internal device-specific messages, e.g. IETF SIP, and external IMS compliant messages, e.g. IMS SIP. The HIGA concept is specified in TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking).
According to 3GPP, it is thus generally required that a communication terminal accessing an IMS network has an “ISIM” (IMS Subscriber Identity Module) application, in order to provide necessary authentication and subscriber data to the IMS network. Among other things, an ISIM typically stores an IMS Private Identity referred to as “IMPI” and at least one IMS Public Identity referred to as “IMPU”, both being registered in the IMS network. In short, IMPI is used for authentication, whereas IMPU is used to identify subscribers and/or profiles for IMS services and may be designed in the manner of an e-mail address or a telephone number.
In
When HIGA 106 receives a request for a multimedia service from a local device in network 100 using a device-specific interface/protocol, HIGA 106 translates the service request into a valid IMS request (typically a SIP INVITE message) to IMS network 108, to set up an IMS session on behalf of the local device using an IMS identity 112 associated with the device 100a. In a similar manner, HIGA 106 can also set up a media session with a local device when receiving a session request originating from an external device 114 outside the network 100. In either case, the media is transported over the RGW 102 and the access network 104 during the actual session, as indicated by two-way arrows.
It has also been proposed to use one or more shared IMS identities 112 in the HIGA which are allocated to the local devices on a session basis, i.e. the used IMS identity is released after the session is finished. Thereby, it is not necessary to maintain one dedicated IMS identity 112 for each local device both in the HIGA and in the IMS, which may involve a large number of IMS identities.
However, the local devices in the local network cannot be discerned in the IMS network if shared IMS identities are used, and the HIGA is therefore responsible for deciding which device(s) to alert upon incoming calls and session requests directed to such an IMS identity. Using shared IMS identities thus makes the local devices “anonymous” and indefinite to external entities and networks, unless a dedicated IMS identity is reserved for each local device, as described above.
In either case, the HIGA must be capable of handling incoming and outgoing calls and session requests to and from individual local devices which requires a certain complexity in the HIGA. This can sometimes be problematic since HIGA products that can be bought “off-the-shelf” from standard retailers are quite simple and may often lack the required functionality.
For example, the HIGA must be equipped with software capable of determining which local device(s) to connect for different incoming calls and session requests, e.g. depending on the called number and/or the type of communication and capabilities of the different devices in the local network. Some devices may be more suitable for certain types of sessions than other devices, and so forth.
This type of functionality would make the HIGA products more expensive, among other things. Moreover, a user must input an IMPU or the equivalent as a wanted public identity when making an IMS registration from a local device which may be perceived as an awkward or difficult task. The software in the HIGA may also need updating and/or error correction.
It is an object of the invention to basically address at least some of the problems outlined above. Further, it is an object to support registration of a local terminal with an external multimedia services network such as an IMS network, and to enable reduced complexity in the home gateway. These objects and others may be obtained by providing a method and arrangement according to the independent claims attached below.
According to one aspect, a method is provided in a home gateway of a local network for providing registration in an external multimedia services network for one or more local devices present in the local network. When a local registration request is received from a first local device, a mapping or association of a corresponding identification of the first local device to a first public identity which is valid in the multimedia services network, is stored. The first public identity is then registered together with the identification of the first local device in the multimedia services network for the first local device. Thereby, any incoming call or session request referring to the first public identity will be directed by the multimedia services network to the first local device.
According to another aspect, an arrangement is provided in a home gateway of a local network, the arrangement being capable of providing registration in an external multimedia services network for one or more local devices present in the local network. The home gateway arrangement comprises a receiving unit configured to receive a local registration request from a first local device, and a mapping unit configured to store a mapping or association of a corresponding identification of the first local device to a first public identity which is valid in the multimedia services network. The inventive home gateway arrangement further comprises a registration unit configured to register the first public identity together with the identification of the first local device in the multimedia services network for the first local device, such that any incoming call or session request referring to the first public identity will be directed by the multimedia services network to the first local device.
If the above method and/or home gateway arrangement is used, the home gateway can be made less complex since the functionality of selecting called device in the local network for incoming calls will be simpler as compared to the prior art. Different embodiments are possible in the method and home gateway arrangement above.
In one exemplary embodiment, whenever local registration requests are received from one or more further local devices in the local network, the first public identity is registered as a shared public identity together with each local device identification in the multimedia services network for each associated local device. Thereby, any incoming call or session request referring to the first public identity will be directed by the multimedia services network as separate calls or session requests to each associated local device.
According to another embodiment, when a local registration request indicating a wanted second public identity is received from a second local device, the second public identity is registered as an individual public identity together with the identification of the second local device in the multimedia services network for the second local device. Any incoming call or session request referring to the second public identity will then be directed by the multimedia services network only to the second local device.
According to yet another embodiment, when a local registration request indicating a wanted third public identity is received from a local device operated by a particular user, the third public identity is registered as an individual public identity together with the user identification in the multimedia services network for the user. Any incoming call or session request referring to the third public identity will then be directed by the multimedia services network only to a local device operated by that user.
In other possible embodiments, each registering operation may include sending an external registration request to the multimedia services network comprising one of the public identities and one of the identifications of local device(s) or user in a contact header of the external registration request. The public identities may be defined in the form of telephone numbers and/or e-mail addresses. Also, the stored mapping or association may used for determining which public identity to use for outgoing calls or session requests. For example, internal device-specific messages according to IEFT SIP may be used for communication with the local devices, and IMS compliant messages according to IMS SIP may be used for communication with the multimedia services network.
Further possible features and benefits of the invention will be explained in the detailed description below.
The invention will now be explained in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:
a, 4b and 4c are schematic block diagrams illustrating different traffic cases for incoming and outgoing calls, in accordance with further possible embodiments.
Briefly described, the invention can be used for a device located within a local network to provide registration with a multimedia services network, which enables direction of incoming calls and session requests to appropriate specific devices in the local network but without requiring a dedicated public identity for each and every device. The home gateway may be a HIGA as specified in TISPAN and the multimedia services network may be an IMS network, although the invention is not limited specifically thereto.
When a local device is powered on or otherwise activated in a local network, it automatically sends a local registration request to the home gateway, which is a perfectly normal behaviour for any local device capable of connecting to a local network. In this solution, the home gateway has been configured, or “provisioned”, with one or more public identities which are also valid in an external multimedia services network, e.g. an IMS network. The operation of configuring a node with various parameters is often generally referred to as “provisioning”.
When receiving the local registration request from the local device, the home gateway stores a mapping or association of an identification of the local device to such a preconfigured public identity, and also registers that public identity along with the local device identification in the multimedia services network for the associated local device. Thereby, the multimedia services network will have knowledge of which local device to contact whenever an incoming call or session request referring to that public identity is received from a remote party, e.g. a telephone, computer or server. The functionality of determining which local device(s) to connect for different incoming calls and session requests is thus located in the multimedia services network, e.g. as handled by a suitable session control node therein, and the home gateway can be made relatively simple and reasonably priced.
An example of how the above registration can be executed will now be described with reference to a communication scenario shown in
A first step 2:1 illustrates that the home gateway is configured or provisioned with one or more public identities which are also valid in an external multimedia services network, e.g. an IMS network. The public identities may be IMPU:s designed as e-mail addresses or telephone numbers and has been configured in the IMS network as well along with an IMPI or similar when establishing a subscription for the home gateway with the IMS network.
In a next step 2:2, the local device A sends a local registration request to the home gateway 202, e.g. when being powered on or otherwise activated, which is a standard operation when such devices establish a connection in local networks. The home gateway 202 is also able to determine an identification of local device A, e.g. from the received registration request or by means of the internal communication interface used. Typically, the registration request is a SIP REGISTER message containing an identification of the sending device A such as a local source IP address and/or a device identity known to the home gateway 202.
In a further step 2:3, the home gateway 202 stores a mapping or association of an identification of the first local device to one of the public identities preconfigured in the previous step 2:1. This mapping or association may be stored in a local database 202a or the equivalent. Next, the home gateway 202 executes registration, in a step 2:4, of the above selected public identity together with an associated identification of device A in the IMS network, such that local device A is associated to the public identity, e.g. an IMPU, in the IMS network as well.
It should be noted that the identification of device A used in the registration of step 2:4 and/or mapping of step 2:3 could be any type of device identification, thus not necessarily using the one present in the local registration request of step 2:2. For example, a simple naming or the like may be used to indicate device A in the IMS network and/or the mapping above, for instance merely the letter “A”. In another example, the identification of A may contain both its local IP address and some unique ID code. In a practical example, the contact field in the header of a SIP REGISTER message could be:
“Contact: IMPU_Unique_localID@WAN_IP_adress:5060”
The shown procedure may be finished by a suitable acknowledge message “OK” from home gateway 202 to device A, in a step 2:5, which can alternatively be executed at any time after step 2:2. Thereby, any incoming call or session request referring to the public identity registered in step 2:4 will be directed by the IMS network to the associated local device A.
The home gateway 202 may likewise receive local registration requests from one or more further local devices in network 200, not shown in this figure, e.g. when they are powered on or otherwise activated, as part of the normal local connection procedure. Then, a mapping or association of a corresponding local device identification to the same public identity can be stored for each device, and the public identity can be registered as a shared public identity together with each local device identification in the IMS network for each additional local device.
Thereby, any incoming call or session request referring to the registered public identity will be directed by the IMS network to each of the associated local devices. Effectively, all these devices will be called and alerted, e.g. ringing, since the incoming call or session request will be directed by the IMS network to each and every associated device. This functionality is often referred to as “forking”, i.e. the incoming call or session request is branched out into plural separate calls by the IMS network, which will be described further below. In particular, the registered public identity may be used as a common “home” public identity that is shared by multiple devices in the local network, in the sense that any incoming call or session request referring to the registered public identity will be directed by the IMS network to all associated local devices.
However, if a local registration request from a local device indicates a wanted public identity that is to be used exclusively for the requesting local device or its current user, the home gateway stores a mapping or association of a corresponding identification of the local device or user to the indicated public identity. That public identity is then registered as an individual public identity together with the corresponding local device or user identification in the IMS network. Thereby, any incoming call or session request referring to the individual public identity will be directed by the IMS network only to the associated local device or user, i.e. no forking in this case.
The home gateway 202 may be configured to automatically map or associate all registering local devices to the shared home public identity which make local registration requests not specifying any wanted individual public identity. In this way, a mixture of individual and shared public identities can be used in the local network and the functionality of determining which local device(s) to call based on a called public identity, using forking or not, will be located in the IMS network instead of the home gateway. As mentioned above, locating the forking functionality in the IMS network instead of the home gateway enables simpler and less costly home gateways, among other things.
An exemplary procedure for providing registration of a local device with a multimedia services network, will now be described with reference to the flow chart in
In a first step 300, the home gateway is configured or provisioned with one or more public identities valid in the multimedia services network, e.g. IMPU:s, which corresponds basically to step 2:1 above. In a next step 302, the home gateway receives a local registration request from a local device in the network, which corresponds basically to step 2:2 above. Then, one of the above configured public identities, e.g. an IMPU, is determined and selected for the requesting local device, in a following step 304.
As mentioned above, a shared public identity may be selected “by default” for local registration requests not specifying a wanted individual public identity. However, this solution does not exclude the possibility of registering individual public identities as well, e.g. as dictated by manual input in the used device. Alternatively, a local device may be preconfigured to include a certain individual public identity automatically in the local registration request for either belonging exclusively to the device or to the current user.
In a next step 306, a mapping or association of an identification of the local device to the public identity selected in step 304, is stored in the home gateway, which corresponds basically to step 2:3 above. The public identity, e.g. IMPU, is then registered together with a suitable device identification in the multimedia services network, as shown by a further step 308, which corresponds basically to step 2:4 above. Thereby, an association between the public identity and the local device is effectively created in the multimedia services network as well. A suitable registration acknowledge message may also be sent to the local device, e.g. depending on the local device-specific protocol used, as shown by an optional final step 310. Analogous to the example of
Reusing some of the numerals in
Furthermore, devices A and B have both been registered in the manner described for
In the traffic case of
In the traffic case of
In the traffic case of
Thus, home gateway 202 creates an external calling number for the outgoing call by adding the public identity HN valid for device B to the previously registered identification of device B, i.e. HN_B. For example, if SIP is used for the outgoing call, a SIP header may contain parameters such as “From: HN, Contact: HN_B”. As a result, the call coming from HN_B is received by IMS node 400 which then simply removes the identification of device B such that remote party X will receive a call with HN as the calling number.
An example of how the inventive solution can be implemented in practice will now be described in more detail with reference to the signalling diagram in
A first step 5:1 illustrates that a public SIP URI is provisioned or configured as a public identity or IMPU in the HIGA 502, basically corresponding to steps 2:1 and 300 above. In a next step 5:2, device 500 is powered on which triggers a discovery process in a following step 5:3 which is normally conducted when connecting to the local network. The discovery process per se is generally known to any person skilled in the art and is not necessary to describe further to understand this implementation example.
In a next step 5:4, device 500 sends a local registration request to HIGA 502, in this example a SIP REGISTER message which may or may not include a local identity of device 500, basically corresponding to steps 2:2 and 302 above. After deciding that device 500 can use the provisioned public SIP URI as public identity, the HIGA 502 then stores a mapping or association of an identification of device 500 to the public SIP URI, in a following step 5:5. This step basically corresponds to steps 2:3 and 306 above.
A further step 5:6 illustrates the operation of registering the public SIP URI together with an identification of device 500 in the IMS node 504, basically corresponding to steps 2:4 and 308 above. This operation is finished by IMS node 504 sending a SIP 200 OK message in acknowledgement to the HIGA 502, in a next step 5:7. The HIGA 502 may also send a corresponding SIP 200 OK message or similar depending on the local device type, in acknowledgement to the device 500, in another shown step 5:8. Thereby, registration of device 500 with the IMS network is completed.
A further step 5:9 illustrates that an incoming call from a remote party is eventually received by the IMS node 504, the call being directed to the public SIP URI as a “called number” or the equivalent. In a next step 5:10, IMS node 504 determines which device or devices to send the call to, based on the registration made in step 5:6 and any other registrations possibly made in the same manner for further local devices in the local network, if any. Accordingly, IMS node 504 finds out that device 500 is associated to the called public SIP URI and modifies the called number by including the previously registered identification of device 500 with the public SIP URI. The call is forwarded to the HIGA 502 in a next step 5:11, and further calls may be forwarded as well with other local device identifications if further devices are associated to the called public SIP URI, as described above as the forking operation.
HIGA 502 then recognises device 500 from the called number of the incoming call and translates the incoming call into a device-specific call alert in the form of a SIP RINGING message in step 5:12, such that device 500 will be ringing in a final step 5.13. If further calls are received with other local device identifications originating from the same remote party, these further local devices will be alerted as well. However, the HIGA will perceive and process these calls as separate calls independent of each other.
An arrangement in a home gateway will now be described in more detail with reference to the block diagram in
The home gateway 600 is configured for providing registration in an external multimedia services network 604 for local devices present in the local network, basically in the manner described above. The home gateway 600 comprises a receiving unit 600a configured to receive a local registration request from a first local device A, and a mapping unit 600b configured to store 600c a mapping of a corresponding identification of the associated first local device A to a first public identity HN which is valid in the multimedia services network 604. This mapping is stored in a suitable database 600c.
The home gateway 600 further comprises a registration unit 600d configured to register the first public identity HN together with an identification of device A in the multimedia services network for the associated first local device. Thereby, any incoming call or session request referring to the first public identity will be directed by the multimedia services network 604 to the associated first local device A.
The home gateway arrangement in
In another example, when a local registration request indicating a wanted second public identity is received from a second local device, the mapping unit 600b may be further configured to store a mapping or association of a corresponding identification of the second local device to the second public identity. The registration unit 600d is then also configured to register the second public identity as an individual public identity together with the identification of the second local device in the multimedia services network for the associated second local device. Thereby, any incoming call or session request referring to the second public identity will be directed by the multimedia services network only to the associated second local device.
In yet another example, when a local registration request indicating a wanted third public identity is received from a local device operated by a particular user, the mapping unit 600b may be configured to store a mapping or association of a corresponding user identification to the third public identity. The registration unit is then also configured to register the third public identity as an individual public identity together with the user identification in the multimedia services network for the associated user. Thereby, any incoming call or session request referring to the third public identity will be directed by the multimedia services network only to a local device operated by the associated user.
According to another embodiment, the registration unit is further configured to send, in each registering operation, an external registration request to the multimedia services network comprising one of the public identities and one of the identifications of local device(s) or user in a contact header of the external registration request.
While the invention has been described with reference to specific exemplary embodiments, the description is only intended to illustrate the inventive concept and should not be taken as limiting the invention. Although the concepts of HIGA, IMS and SIP have been used when describing the above embodiments, any other similar suitable standards, protocols and network elements may basically be used for providing registration of a local device in a multimedia services network as described herein. The invention is generally defined by the following independent claims.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/SE09/50929 | 8/11/2009 | WO | 00 | 1/26/2012 |
