U.S. patent application number 13/345389 was filed with the patent office on 2012-07-12 for service profile handling in the ims.
Invention is credited to Maria-Carmen Belinchon Vergara, German Blanco Blanco, Nuria Vares Esteban, Hubert Przybysz, Stephen Terrill.
Application Number | 20120178447 13/345389 |
Document ID | / |
Family ID | 34674029 |
Filed Date | 2012-07-12 |
United States Patent
Application |
20120178447 |
Kind Code |
A1 |
Terrill; Stephen ; et
al. |
July 12, 2012 |
Service Profile Handling in the IMS
Abstract
A Home Subscriber Server for handling IP Multimedia Subsystem
subscriptions comprises means for maintaining associations between
public user identities and Service Profiles, where two or more
public user identities can be associated with a common Service
Profile, and means for identifying to a network node all public
user identities that are associated with a common Service
Profile.
Inventors: |
Terrill; Stephen; (Madrid,
ES) ; Esteban; Nuria Vares; (Aranjuez (Madrid),
ES) ; Blanco Blanco; German; (Madrid, ES) ;
Belinchon Vergara; Maria-Carmen; (Getafe (Madrid), ES)
; Przybysz; Hubert; (Hagersten, SE) |
Family ID: |
34674029 |
Appl. No.: |
13/345389 |
Filed: |
January 6, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11913039 |
Oct 29, 2007 |
|
|
|
PCT/EP2006/061880 |
Apr 27, 2006 |
|
|
|
13345389 |
|
|
|
|
Current U.S.
Class: |
455/435.1 |
Current CPC
Class: |
H04L 67/147 20130101;
H04M 3/2272 20130101; H04W 8/04 20130101; H04L 65/1016 20130101;
H04L 67/306 20130101; H04L 67/14 20130101 |
Class at
Publication: |
455/435.1 |
International
Class: |
H04W 60/00 20090101
H04W060/00; H04W 68/00 20090101 H04W068/00 |
Foreign Application Data
Date |
Code |
Application Number |
Apr 29, 2005 |
GB |
0508690.5 |
Jun 29, 2005 |
GB |
0513154.5 |
Claims
1. A Home Subscriber Server for handling IP Multimedia Subsystem
"IMS" subscriptions and comprising: means for maintaining an IMS
subscription with a first, a second and a third public user
identities; means for grouping the first and second public user
identities in an Implicit Registration Set; means for maintaining
associations between public user identities and Service Profiles,
where the third public user identity and at least one of the first
and second public user identities are associated with a common
Service Profile; and, means for identifying to a network node those
public user identities in the Implicit Registration Set along with
each respectively associated Service Profile, and those public user
identities which are associated with the common Service
Profile.
2. A Home Subscriber Server according to claim 1, wherein said
means for identifying are arranged for sending a notification to
the network node in response to a registration or re-registration
procedure, a terminating call or a change of contents in the
Service Profile.
3. A Home Subscriber Server according to claim 1, wherein said
means for identifying comprises means for sending a message to the
network node containing one or more Service Profiles, each Service
Profile identifying those public user identities with which it is
associated.
4. A Home Subscriber Server according to claim 3, wherein said
message also contains, outside of the Service Profiles, those
public user identities in the Implicit Registration Set.
5. A Home Subscriber Server according to claim 3, wherein those
public user identities identified by the common Service Profile are
considered to be alias public user identities.
6. A Home Subscriber Server according to claim 1, wherein said
network node is a Serving Call session Control Function or an
Application Server in the IP Multimedia Subsystem "IMS".
7. A Call Session Control Function for servicing a user in an IP
Multimedia Subsystem network, the Call Session Control Function
comprising: means for receiving from a Home Subscriber Server, a
message containing a first and a second public user identities in
an Implicit Registration Set along with a respectively associated
Service Profile, and a third public user identity associated with a
common Service Profile, wherein the common Service Profile is also
associated with at least one of the first and second public user
identities; and means for associating those public user identities
which are associated with the common Service Profile as alias
public user identities.
8. A Call Session Control Function according to claim 7, wherein
the first and second public user identities in the Implicit
Registration Set are received in a list of public user identities
contained outside of the received Service Profile(s).
9. A Call Session Control Function according to claim 7, comprising
means for sending a notification to a user terminal or network node
identifying those public user identities which are considered to be
alias public user identities associated with the common Service
Profile.
10. A Call Session Control Function according to claim 7, wherein
the Call Session Control Function is a Serving Call Session Control
Function in the IP Multimedia Subsystem "IMS".
11. An Application Server for executing services in an IP
Multimedia Subsystem network, the Application Server comprising:
means for receiving from a Serving Call Session Control Function or
a Home Subscriber Server, a notification identifying two or more
public user identities which are considered to be alias public user
identities associated with a common Service Profile.
12. A user terminal for a enabling a user to access an IP
Multimedia Subsystem network, the user terminal comprising: means
for receiving from a Serving Call Session Control Function or an
Application Server, a notification identifying two or more public
user identities of the terminal which are considered to be alias
public user identities associated with a common Service
Profile.
13. A method of operating an IP Multimedia Subsystem to inform
network nodes and/or user terminals of public user identities to be
considered as alias public user identities, the method comprising:
maintaining at a Home Subscriber Server an IMS subscription with a
first, a second and a third public user identities; grouping at the
Home Subscriber Server the first and second public user identities
in an Implicit Registration Set; maintaining at the Home Subscriber
Server associations between public user identities and Service
Profiles, where the third public user identity and at least one of
the first and second public user identities are associated with a
common Service Profile; and, identifying, from the Home Subscriber
Server to a network node, those public user identities in the
Implicit Registration Set along with each respectively associated
Service Profile, and those public user identities which are
associated with the common Service Profile.
14. A method according to claim 13, comprising sending from the
Home Subscriber Server to a Serving Call Session Control Function a
message containing one or more Service Profiles, each Service
Profile identifying those public user identities associated with
the Service Profile, and the Serving Call Session Control Function
associating those public user identities which are associated with
the common Service Profile as alias public user identities.
15. A method according to claim 13, comprising the Serving Call
Session Control Function notifying an application server or user
terminal of those public user identities which are considered to be
alias public user identities associated with the common Service
Profile.
16. A method according to claim 14, wherein the public user
identities in the Implicit Registration Set are listed in said
message outside of the one or more Service Profiles.
17. A method according to claim 14, wherein the message identifies
the common Service Profile whose associated public user identities
are considered to be alias public user identities.
18. A method according to claim 13, wherein the step of identifying
is carried out during or subsequent to registration of a user
terminal with the IP Multimedia Subsystem, or upon or subsequent to
terminating a call to a user terminal, or upon or subsequent to a
change of content of the Service Profile.
19. A method according to claim 15, wherein a user terminal is
notified that two or more of its public user identities are alias
public user identities from the application server.
20. A method of operating a user terminal configured for use with
an IP Multimedia Subsystem, the method comprising: receiving from a
Serving Call Session Control Function or an Application Server, a
notification identifying two or more public user identities of the
terminal which are considered to be alias public user identities
associated with a common Service Profile.
21. A method of operating a Session Initiation Protocol Application
Server of an IP Multimedia Subsystem, the method comprising:
receiving from a Serving Call Session Control Function or a Home
Subscriber Server, a notification identifying two or more public
user identities which are considered to be alias public user
identities associated with a common Service Profile and for the
purpose of handling service configurations.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to a method and apparatus for
Service Profile handling in the IP Multimedia Subsystem.
BACKGROUND TO THE INVENTION
[0002] IP Multimedia Subsystem (IMS) is the technology defined by
the Third Generation Partnership Project (3GPP) to provide IP
Multimedia services over mobile communication networks (3GPP TS
22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and
TS 29.329 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 (UEs) or between UEs and application servers (ASs). The
Session Description Protocol (SDP), carried by SIP signalling, is
used to describe and negotiate the media components of the session.
Whilst SIP was created as a user-to-user protocol, IMS allows
operators and service providers to control user access to services
and to charge users accordingly.
[0003] FIG. 1 illustrates schematically the IMS architecture and
its internal and external interfaces. Call/Session Control
Functions (CSCFs) operate as SIP entities within the IMS. The 3GPP
architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF)
which is the first point of contact within the IMS for a SIP
terminal; the Serving CSCF (S-CSCF) which provides services to the
user that the user is subscribed to; and the Interrogating CSCF
(I-CSCF) whose role is to identify the correct S-CSCF and to
forward to that S-CSCF a request received from a SIP terminal via a
P-CSCF.
[0004] A user registers in the IMS using the specified SIP REGISTER
method. This is a mechanism for attaching to the IMS and announcing
to the IMS the address at which a SIP user identity can be reached.
In 3GPP, when a SIP terminal performs a registration, the IMS
authenticates the user, and allocates a S-CSCF to that user from
the set of available S-CSCFs. Whilst the criteria for allocating
S-CSCFs is not specified by 3GPP, these may include load sharing
and service requirements. It is noted that the allocation of an
S-CSCF is key to controlling, and charging for, user access to
IMS-based services. Operators may provide a mechanism for
preventing direct user-to-user SIP sessions which would otherwise
bypass the S-CSCF.
[0005] During the registration process, it is the responsibility of
the I-CSCF to select an S-CSCF, if an S-CSCF is not already
selected. The I-CSCF receives the required S-CSCF capabilities from
the home network's Home Subscriber Server (HSS), and selects an
appropriate S-CSCF based on the received capabilities. It is noted
that S-CSCF allocation is also carried for a user by the I-CSCF in
the case where the user is called by another party, and the user is
not currently allocated an S-CSCF. When a registered user
subsequently sends a session request to the IMS, the P-CSCF is able
to forward the request to the selected S-CSCF based on information
received from the S-CSCF during the registration process.
[0006] Every IMS user possesses one or more Private User
Identities. A Private User Identity is assigned by the home network
operator and is used by the IMS, for example for registration,
authorisation, administration, and accounting purposes. This
identity takes the form of a Network Access Identifier (NAI) as
defined in RFC 2486. It is possible for a representation of the
International Mobile Subscriber Identity (IMSI) to be contained
within the NAI for the private identity. 3GPP TS 23.228 specifies
the following properties of the Private User Identity: [0007] The
Private User Identity is not used for routing of SIP messages.
[0008] The Private User Identity shall be contained in all
Registration requests, (including Re-registration and
De-registration requests) passed from the UE to the home network.
[0009] An IP multimedia Services Identity Module (ISIM) application
shall securely store one Private User Identity. It shall not be
possible for the UE to modify the Private User Identity information
stored on the ISIM application. [0010] The Private User Identity is
a unique global identity defined by the Home Network Operator,
which may be used within the home network to identify the user's
subscription (e.g. IM service capability) from a network
perspective. The Private User Identity identifies the subscription,
not the user. [0011] The Private User Identity shall be permanently
allocated to a user's subscription (it is not a dynamic identity),
and is valid for the duration of the user's subscription with the
home network. [0012] The Private User Identity is used to identify
the user's information (for example authentication information)
stored within the HSS (for use for example during Registration).
[0013] The Private User Identity may be present in charging records
based on operator policies. [0014] The Private User Identity is
authenticated only during registration of the user, (including
re-registration and de-registration). [0015] The HSS needs to store
the Private User Identity. [0016] The S-CSCF needs to obtain and
store the Private User Identity upon registration and unregistered
termination.
[0017] In addition to a Private User Identity, every IMS user shall
have one or more IMS Public User Identities (IMPUs). The IMPUs are
used by any user to request communications to other users. A user
might for example include an IMPU (but not a Private User Identity)
on a business card. 3GPP TS 23.228 specifies the following
properties of the IMPU: [0018] Both telecom numbering and Internet
naming schemes can be used to address users depending on the IMPUs
that the users have. [0019] The IMPU(s) shall take the form of a
SIP URI (as defined in RFC 3261 and RFC 2396 or the "tel:"-URI
format defined in RFC 3966. [0020] An ISIM application shall
securely store at least one IMPU (it shall not be possible for the
UE to modify the IMPU), but it is not required that all additional
IMPUs be stored on the ISIM application. [0021] An IMPU shall be
registered either explicitly or implicitly before the identity can
be used to originate IMS sessions and IMS session unrelated
procedures. [0022] An IMPU shall be registered either explicitly or
implicitly before terminating IMS sessions and terminating IMS
session unrelated procedures can be delivered to the UE of the user
that the IMPU belongs to. [0023] It shall be possible to register
globally (i.e. through one single UE request) a user that has more
than one IMPU via a mechanism within the IMS (e.g. by using an
Implicit Registration Set). This shall not preclude the user from
registering individually some of his/her IMPUs if needed. [0024]
IMPUs are not authenticated by the network during registration.
[0025] IMPUs may be used to identify the user's information within
the HSS (for example during mobile terminated session set-up).
[0026] IMPUs may be used by ASs within the IMS to identify service
configuration data to be applied to a user.
[0027] FIG. 2 illustrates schematically example relationships
between a user (IMS) subscription and the Public and Private User
Identities. In the example shown, a subscriber has two Private User
Identities, with both being associated with two Public User
Identities (one of the Public User Identities, Public User
Identities-2, being associated with both Private User Identities).
A Service Profile is associated with each Public User Identities,
this profile specifying service data for the associated Public User
Identities. A Service Profile is created or modified when an
application server is provisioned for a user at the Home Subscriber
Server. Each Service Profile comprises one or more initial Filter
Criteria (iFC) which are used to trigger the provision, or
restriction, of IMS services. The differences between services
offered by Service Profile-1 and Service Profile-2 are operator
specific, but may involve different application servers (ASs), and
even different charging/rating schemes.
[0028] In the example, Public User Identity-1 is associated with a
Service Profile-1, whilst Public User Identity-2 and Public User
Identity-3 are associated with Service Profile-2. In a typical
scenario, the Public User Identity-1 might be an identity that the
user gives to friends and family, e.g. "Big_Joe@priv.operator.com",
whilst Public User Identity-2 and Public User Identity-3 might be
identities that the user gives to business contacts, e.g.
"+46111222333@operator.com" and "joe.black@operator.com".
[0029] Within the IMS service network, application servers (ASs)
are provided for implementing IMS service functionality. For any
given UE, one or more ASs may be associated with that terminal.
FIG. 3a illustrates the IMS Service Control (ISC) interface between
an AS and an S-CSCF, as well as other interfaces within the IMS.
Although the AS in FIG. 3a is shown as having only a single
interface to an S-CSCF, it will be appreciated that in practice the
ISC interface will extend across a communication network to which
many (or all) of the CSCF servers of a given operator's network are
connected, allowing an AS to communicate with all of these CSCFs.
[Other entities illustrated in FIG. 3a will be well known to those
of skill in the art.]
[0030] A further interface (Ut) exists between the AS and the UE
(TS23.002) as illustrated in FIG. 3b. The Ut interface enables the
user to manage information related to his or her services, e.g.
creation and assignment of Public Service Identities, management of
authorisation policies that are used for example by "presence"
services, conference, policy management, etc.
SUMMARY OF THE INVENTION
[0031] According to TS 23.228, the association between IMPUs and
Service Profiles, and in particular the linking of multiple IMPUs
to a single Service Profile, is known to the Home Subscriber Server
(HSS). However, this linking only indicates the IMPUs that share
the same set of filter criteria; subscribed media etc, and provides
no indication about the general user profiles stored outside the
HSS (e.g. in application servers) and makes no assumptions about
the relationships between the IMPUs that share the same service
profile (i.e. whether they are an "alias.degree. or not).
[0032] The inventors of the present invention have recognised that
entities other than the HSS and the S-CSCF, including any
Application Server(s) associated with a UE and the UE itself, are
not provided with information associating service profiles with
IMPUs, and yet these other entities could make use of the
information. For example, an Application Server may wish to link
together service configuration information associated with two
IMPUs based upon these two IMPUs sharing a single Service
Profile.
[0033] In the example described above with reference to FIG. 2,
Public User Identity-1 is associated with a personal profile for
non-business usage, and Public User Identity-2 and Public User
Identity-3 are for business purposes and are expected to have the
same service configuration data. It is necessary to treat actions
and data related to Public User Identity-1 differently from actions
and data related to Public User Identity-2 or Public User
Identity-3, whilst treating actions and data associated with Public
User Identity-2 and Public User Identity-3 in the same way. Thus,
for example, originating sessions and terminating sessions for
Public User Identity-2 and Public User Identity-3 are treated in
the same way, as is supplementary service settings data such as
"do-not-disturb" for the IMS-based Push-to-talk over Cellular (PoC)
service, or a call-forwarding address multimedia telephony
assumption.
[0034] Without the knowledge that a plurality of IMPUs are
associated, an application server must store in its memory a
service configuration for each IMPU. This has a serious impact on
memory requirements when large numbers, e.g. millions, of IMPUs are
active. Similarly, if a UE does not have this knowledge, the
terminal would not know, for example, whether an operation over the
Ut interface has to be repeated for each public user identifier.
Where a user updates a call forwarding number via the Ut Interface
for multimedia telephony, the terminal does not have sufficient
information as to which IMPUs it should do this for, e.g. does
updating the call forwarding number for Public User Identity-3
imply that it is automatically updated for Public User Identity-2,
or should the terminal also send Ut interface requests for Public
User Identity-2: this misunderstanding could cause problems on some
Ut interface requests such as adding a user to a group (at an
application ever) in the case that the network and the UE have
different understandings.
[0035] For the currently specified 3GPP releases, the IMS entities
(including UEs) assume that all IMPUs are treated
independently.
[0036] It is an object of the present invention to provide a means
for informing entities other than the HSS of relationships between
IMPUs and Service Profiles.
[0037] According to a first aspect of the present invention there
is provided a Home Subscriber Server for handling IP Multimedia
Subsystem subscriptions and comprising: [0038] means for
maintaining associations between public user identities and Service
Profiles, where two or more public user identities can be
associated with a common Service Profile; and [0039] means for
identifying to a network node all public user identities that are
associated with a common Service Profile.
[0040] Embodiments of the present invention are able to both reduce
the memory storage requirements at a SIP application server or
other network node, and reduce the signalling load within the IP
Multimedia Subsystem and associated networks.
[0041] Preferably, said means for identifying sends a notification
to the network node in response to a registration or
re-registration procedure, a terminating call or a change of
contents in the Service Profile.
[0042] Preferably, said means for Identifying to a network node all
public user identities associated with a common Service Profile,
comprises means for sending a message to the network node
containing one or more Service Profiles, each Service Profile
identifying all public user identities with which it is
associated.
[0043] According to an embodiment of the present invention, said
message also contains, outside of the Service Profiles, a set of
public user Identities belonging to a common Implicit Registration
Set.
[0044] According to an embodiment of the present invention, said
message identifies one or more Service Profiles contained within
the message, the public user identities of each identified Service
Profile being considered alias public user identities.
[0045] The term "alias" as used here is considered a term of the
art. It means that use or reference to one of the alias IMS Public
User Identities is also use of or a reference to the other alias
Public User Identity(ies), i.e. the network behaviour is, as a
rule, identical for all alias identities. For example, a service
data/configuration change request sent to an application server in
respect of one alias IMS Public User Identity should be treated as
a change request also for the other alias Public User
Identity(ies). Of course, there may be exceptional cases where a
service data/configuration change is relevant for only one of the
alias Public User Identity(ies), for example the deletion of one of
the alias Public User Identity(ies) from the network, or a change
of the assigned Service Profile for an alias IMS Public User
Identity.
[0046] Said network node may be a Serving Call session Control
Function.
[0047] Said means for identifying may convey the required
information to a Serving Call Session Control Function in a Cx
Server Assignment Answer or Push Profile Request message.
[0048] According to a second aspect of the present Invention there
is provided a Home Subscriber Server for handling IP Multimedia
Subsystem subscriptions and comprising: [0049] means for
maintaining groupings of public user identities that are to be
considered alias public user identities; and [0050] means for
sending to a network node an identification of aliasing groups.
[0051] Preferably, said means for sending to a network node an
identification of aliasing groups, sends this information in
response to a registration or re-registration procedure, a
terminating call or a change of contents in a Service Profile.
[0052] Said network node may be a Serving Call session Control
Function or an application server.
[0053] According to a third aspect of the present invention there
is provided a Call Session Control Function for servicing a user in
an IP Multimedia Subsystem network, the Call Session Control
Function comprising: [0054] means for receiving from a Home
Subscriber Server, a message containing one or more Service
Profiles, the or each Service Profile identifying all public user
identities with which the Service Profile is associated; and [0055]
means for associating the public user identities of at least one
Service Profile as alias public user identities.
[0056] Said Call Session Control Function may comprise means for
identifying public user identities belonging to an Implicit
Registration Set using a list of public user identities contained
outside of the received Service Profile(s).
[0057] Said Call Session Control Function may comprise means for
identifying Service Profiles to which the aliasing association is
to be applied.
[0058] Preferably, said Call Session Control Function comprises
means for sending a notification to a user terminal or network node
identifying the public user Identities identified as being alias
public user Identities. Said Call Session Control Function may be a
Serving Call Session Control Function.
[0059] According to a fourth aspect of the present invention there
is provided an Application Server for executing services in an IP
Multimedia Subsystem network, the Application Server comprising:
[0060] means for receiving from a Serving Call Session Control
Function or a Home Subscriber Server, a notification that two or
more public user identities are considered to be alias public user
identities.
[0061] According to a fifth aspect of the present invention there
is provided a user terminal for a enabling a user to access an IP
Multimedia Subsystem network, the user terminal comprising: [0062]
means for receiving from the IP Multimedia Subsystem network, a
notification that two or more public user identities of the
terminal are considered to be alias public user identities.
[0063] Preferably, said means is arranged in use to receive said
notification from a Serving Call Session Control Function.
[0064] According to a sixth aspect of the present invention there
is provided a method of operating an IP Multimedia Subsystem to
inform network nodes and/or user terminals of public user
identities to be considered as alias public user identities, the
method comprising: [0065] maintaining at a Home Subscriber Server
groupings of public user identities to be considered as alias
public user identities; and [0066] distributing the grouping
information to network nodes and/or user terminals.
[0067] Preferably, said groupings are maintained in Service
Profiles, as the public user identities associated with the Service
Profiles.
[0068] Preferably, said method comprises sending from the Home
Subscriber Server to a Serving Call Session Control Function a
message containing one or more Service Profiles, the or each
Service Profile identifying all public user identities associated
with the Service Profile, and the Serving Call Session Control
Function identifying all public user identities associated with at
least one Service Profile as alias public user identities.
[0069] Said message may be a Cx Server Assignment Answer or Push
Profile Request message
[0070] The Serving Call Session Control Function may inform an
application server or user terminal of a group of public user
identities to be considered alias public user identities.
[0071] Public user identities belonging to an Implicit Registration
Set may be listed in said message, but outside of the Service
Profile(s).
[0072] The message may identify those Service Profiles whose
associated public user identities are to be considered alias public
user identities.
[0073] Said step of distributing may be carried out during or
subsequent to registration of a user terminal with the IP
Multimedia Subsystem, or upon or subsequent to terminating a call
to a user terminal, or upon a change of content of the Service
Profile.
[0074] Said step of distributing may comprise sending grouping
information to an application server over the Sh interface.
[0075] A user terminal may be notified that two or more of its
public user identities are alias public user identities by
signalling sent from an Application Server over the Ut
interface.
[0076] According to a seventh aspect of the present invention there
is provided a method of operating a user terminal configured for
use with an IP Multimedia Subsystem, the method comprising: [0077]
receiving from the Subsystem, a notification that two or more
public user identities of the terminal are to be considered alias
public user identities.
[0078] According to an eighth aspect of the present invention there
is provided a Session Initiation Protocol Application Server of an
IP Multimedia Subsystem, the method comprising: [0079] receiving
from a Serving Call/Session Control Function or a Home Subscriber
Server, a notification that two or more public user identities are
to be considered alias public, user identities for the purpose of
handling service configurations.
[0080] According to a ninth aspect of the present invention there
is provided a method of operating a Home Subscriber Server in an IP
Multimedia Subsystem, the method comprising: [0081] maintaining at
the Home Subscriber Server groupings of public user identities to
be considered as alias public user identities; and [0082]
distributing the grouping information to network nodes and/or user
terminals.
[0083] According to a tenth aspect of the present invention there
is provided an IP Multimedia Subsystem comprising: [0084] a Home
Subscriber Server arranged to maintain groupings of public user
identities to be considered as alias public user identities, and
having means arranged, during or subsequent to registration of a
user terminal with the IP Multimedia Subsystem, or upon or
subsequent to terminating a call to a user terminal, to inform the
terminal and/or a network node of the grouping containing a public
user identity of the terminal or terminal user.
BRIEF DESCRIPTION OF THE DRAWINGS
[0085] FIG. 1 illustrates schematically an IP Multimedia Subsystem
architecture;
[0086] FIG. 2 illustrates schematically example relationships
between a user IMS subscription and the Public and Private User
Identities; and
[0087] FIGS. 3a and 3b illustrates schematically certain entities
of the IP Multimedia Subsystem including an application server and
a Serving Call/Session Control Function;
[0088] FIG. 4 illustrates schematically the structure of a Service
Profile;
[0089] FIG. 5 illustrates schematically how data of a Service
Profile are downloaded to a Serving Call/Session Control
Function;
[0090] FIG. 6 illustrates schematically the structure of User Data
carried on the Cx interface; and
[0091] FIG. 7 illustrates schematically the relationship and
interfaces between entities of an IP Multimedia Subsystem;
[0092] FIG. 8 illustrates schematically the structure of a Service
Profile according to an embodiment of the present invention.
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
[0093] As has already been discussed, the IP Multimedia Subsystem
(IMS) architecture identifies IMS users using Private User
Identities. It is the Private User Identity that is used to
authenticate a user upon initial registration with the IMS. A
user's location on the other hand is identified by one or more IMS
Public User Identities (IMPUs), and it is an IMPU that is used by
third parties to contact the IMPU owner. Within a Home Subscriber
Server (HSS) located within the home network (e.g. 3G core
network), each IMPU is associated with a Service Profile. A Service
Profile contains service data for these IMPUs, including a set of
initial Filter Criteria (iFC) that are used to trigger the
provision or restriction of IMS services. 3GPP defines the Service
Profile structure shown in FIG. 4, and indicates the way in which
this data is downloaded to the S-CSCF, as illustrated in FIGS. 5
and 6. Further details can be found in TS 29.228 and TS 29.229.
[0094] Within the HSS, one or more IMPUs may be associated with the
same Service Profile. IMPUs associated with the same Service
Profile are referred to here as "alias" IMPUs. 3GPP mandates that
whenever a user is being registered to the IMS network with an
IMPU, the HSS sends to the S-CSCF the Service Profile associated
with that IMPU. 3GPP further mandates that whenever an unregistered
user receives a terminating call from the IMS network, the HSS
sends to the S-CSCF the Service Profile associated with the called
user's IMPU. Whenever a Service Profile is modified in the HSS, the
HSS must send the modified Service Profile to the S-CSCF for each
associated IMPU.
[0095] 3GPP defines a so-called "Implicit Registration Set" concept
to identify a set of IMPUs that work as a group, and which are
registered and deregistered together when any one of the IMPUs of
the set is registered or deregistered. 3GPP mandates that the HSS
send the Implicit Registration Set to the S-CSCF upon registration
of a user or upon terminating a call. It has been understood that
(at registration or call termination) the HSS identifies all IMPUs
within the Implicit Registration Set, and then identifies all of
the Service Profiles associated with these IMPUs. The Service
Profiles (or selected data from the Service Profiles) containing
the IMPUs with which they are associated, are then sent to the
S-CSCF. This is illustrated in FIG. 6. As a result of this
operation, the S-CSCF knows all of the IMPUs that belong to the
same Implicit Registration Set, as well as their Service
Profiles.
[0096] As has already been noted, the fact that two or more IMPUs
are associated with a single Service Profile (within the HSS) can
be used to associate service configuration data for these IMPUs at
other network nodes or at the user terminal (UE). It might be
thought that the Implicit Registration Set concept provides an
appropriate vehicle for distributing associations between IMPUs and
Service Profiles through the IMS (at least between the HSS and the
S-CSCF). However, such an approach would run counter to the
intended purpose of the Implicit Registration Set, i.e. to
implicitly register a number of IMPUs independently of the Service
Profiles with which the IMPUs are associated. For example, it may
well be desirable to include both personal and business related
IMPUs in a user's Implicit Registration Set, whilst maintaining
separate Service Profiles for the two types of identities. This
will be clear from the example of FIG. 6, where IMPUs Public id.1,
Public id.2, and Public id.3 belong to the same Implicit
Registration Set, but are not all associated with the same Service
Profile. It is important therefore that the alias IMPUs are not
bound to the Implicit Registration Set.
[0097] A preferred approach is to expose the IMPUs associated with
a Service Profile on the Ut, Sh, ISC and/or Gm interfaces, and to
inform network nodes or UEs receiving this information that IMPUs
associated with the same Service Profile should be considered alias
public user identities. FIG. 7 shows the various interfaces that
can be used to distribute the relationship between IMPUs and
Service Profiles from the HSS to entities such as the S-CSCF, the
AS and the terminal. The HSS makes the information available to the
S-CSCF over the Cx interface, and to the ASs via the Sh interface
after registration (possibly initiated due to the registration
process). The S-CSCF makes the information available to the P-CSCF
over the Mw interface (not shown in the Figures), and the P-CSCF
exposes this to the terminal over the Gm interface during
registration. The S-CSCF also makes this available to the AS over
the ISC interface.
[0098] The Sh interface should also be able to recognise that IMPUs
associated with the same Service Profile access the same data in
the HSS. Operations performed over the Ut and the Sh interfaces for
one IMPU are deemed to have been performed for all IMPUs associated
with the same Service Profile. [The Service Profile may be
completely contained in an implicit registration set, though an
implicit registration can encompass more than one Service Profile.]
[0099] A number of different solutions as to how the S-CSCF can
receive and interpret the grouping set from the HSS are
envisaged.
[0100] Solution A1: Advertise the IMPUs Belonging to a Service
Profile within the Service Profile
[0101] The grouping of IMPUs belonging to a Service Profile must
coexist with the Implicit Registration Set within the same commands
over the Cx interface, and shall be advertised whenever the user
profile is downloaded from the HSS, i.e., at registration (or
re-registration), termination of a call, or when the user profile
is changed in the HSS.
[0102] This solution requires that the Implicit Registration Set be
advertised in a new information element (attribute value pair or
AVP) alongside the Service Profile. The grouping concept (alias
public user identities) is advertised inside the Service Profile as
transferred on the Cx interface whenever the user profile is
downloaded. That is, the Implicit Registration Set is explicitly
indicated on the Cx interface; and the IMPUs included in the
Service Profile (as transmitted on the Cx interface) indicate the
alias grouping. The Cx messages which carry the Service Profiles
are the Server Assignment Answer (SAA) and the Push Profile Request
(PPR). In this solution, the Service Profile stored at the HSS
remains unchanged, as it is defined in TS 29.228 (see FIG. 5), but
it is indicated that the public Identification instance refers to
the IMPUs that are related to that Service Profile.
[0103] The Cx interface is modified in the following way, where the
underlined text identifies the new AVPs:
TABLE-US-00001 downloading of the profile at registration or
terminating call time (SAA) <Server-Assignment-Answer> ::=
< Diameter Header: 301, PXY, 16777216 > < Session-Id >
{ Vendor-Specific-Application-Id } [ Result-Code ] [
Experimental-Result ] { Auth-Session-State } { Origin-Host } {
Origin-Realm } [ User-Name ] *[Public-Identity]->set of implicit
registration set, if exists *[ Supported-Features ]
[User-Data]->contains the IMPUs related to a SP according
to.29.228 annex D [ Charging-Information ] *[ AVP ] *[ Failed-AVP ]
*[ Proxy-Info ] *[ Route-Record ] downloading of the profile when
the profile changes (PPR) < Push-Profile-Request > ::= <
Diameter Header: 305, REQ, PXY, 16777216 > < Session-Id >
{ Vendor-Specific-Application-Id } { Auth-Session-State } {
Origin-Host } { Origin-Realm } { Destination-Host } {
Destination-Realm } { User-Name } *[Public-Identity]->set of
implicit registration set, if exists *[ Supported-Features ]
[User-Data) ->contains the IMPUs related to a SP according to
29.228 annex D [ Charging-Information ] *[ AVP ] *[ Proxy-Info ) *[
Route-Record ]
[0104] where the User Data is according to TS 29.228 and as
illustrated in FIG. 6.
[0105] Solution A2: Define the Grouping Concept within the
Interfaces
[0106] This approach is to introduce a new grouping concept into
the HSS that identifies which IMPUs are associated. It requires
that the Service Profile as defined in TS 29.228 be modified by
adding a new instance called SProfile Identifier. This is
illustrated in FIG. 8. The SProfile Identifier instance indicates
all IMPUs belonging to that Service Profile. The Implicit
Registration Set is kept within the Service Profile. This would
result in an additional AVP on the Cx interface (within the SAA or
PPR) which would transport the information about the IMPUs which
are considered alias public user identities.
[0107] Solution A3: Introduce Indication of Alias
Interpretation
[0108] Considering further solution Al, this can be simplified by
making the assumption that IMPUs associated with a single Service
Profile will always belong to the same Implicit Registration Set.
Assuming that the aliasing concept is turned on for all Service
Profiles, there is no need to identify any IMPUs outside of the
Service Profile data carried on the line. However, if the aliasing
concept is not turned on by default, it will be necessary to
identify those Service Profiles to which aliasing applies.
Referring to FIG. 6, it may be, for example, that aliasing is
turned on only for Service Profile 1. [0109] Different solutions
are envisaged as to how the application server can receive the
grouping set.
[0110] Solution B1: The S-CSCF Reports the Information Via the ISC.
A Number of Implementations are Possible. [0111] a) Advertise the
IMPUs belonging to a single Service Profile in the 3rd party
registration. [0112] As per the existing 3GPP specifications, an
S-CSCF can be instructed to send a SIP REGISTER message to an
application server. This is known as a 3rd party registration. This
approach is to include new data in the registration message between
the S-CSCF and the application server which conveys the information
about which IMPUs are alias public user identities. [0113] b)
Advertise the IMPUs belonging to a single Service Profile by
subscribing to a registration event. [0114] Currently, in order for
an application server to obtain information about the implicitly
registered IMPUs, an application server can subscribe (send a
SUBSCRIBE message) to the S-CSCF which previously sent a REGISTER
message to the application server. The S-CSCF will then send a
NOTIFY message to the application server containing information
about the registered IMPUs. The proposal is to extend the contents
of the NOTIFY message to include information about which IMPUs are
alias public user identities.
[0115] Solution B2: The AS Receives the Information Via the Sh
[0116] The AS asks for the IMPU alias information via the Sh
interface in the same way that it already asks for the IMPUs
belonging to an Implicit Registration Set or the IMPUs under the
same IMPI.
[0117] Currently The AS sends a Sh-Read to the HSS indicating
within Identity-Set AVP: [0118] ALL_IDENTITIES (0) [0119]
REGISTERED_IDENTITIES (1) [0120] IMPLICIT _IDENTITIES (2)
[0121] In order to cause the Service Profile grouping to be
downloaded, a new value is added to the message: [0122]
SERVICE_PROFILE_IDENTITIES (3)
[0123] Hence the HSS receives a Public-Identity as entry key (when
any operation is made via Ut e.g.), and returns all other IMPUs
associated with the same profile as the IMPU that the HSS indicated
in the request. [0124] Different solutions are also envisaged as to
how the mobile terminal can receive the grouping set.
[0125] For example, two possible solutions are:
[0126] Solution C1: Include the Grouping of the IMPUs in the 200 OK
Message of the Registration Phase.
[0127] Include the information of grouping of the public user
identifiers in the 200 OK sent in response to the Registration
message. This would be in the form of an additional SIP header to
the implicit registration set.
[0128] Solution B2: Include the Grouping of the IMPUs in the
Registration Event Package.
[0129] Include the information of the grouping of the IMPUs in the
NOTIFY message sent in response to the registration event
package.
[0130] Solutions B1 and B2 complement each other and so are not
necessarily mutually exclusive alternatives.
[0131] Whilst the mechanisms described above relate to the
distribution of data within one operator network and the mobile
terminals that connect to that network, the underlying principle of
sharing grouping information extends to passing the grouping
information to other networks (by including the relevant
information on the Network-Network Interface), e.g. between the
network of an operator A and the network of an operator B. Two
examples are given here to illustrate when it could be of interest
to pass grouping information from one network to another
network.
[0132] 1. Presence:
[0133] A subscriber of operator A (user A) includes a subscriber of
operator B as an allowed presence watcher (user B), i.e. user A has
authorised user B (using a particular Public User Identifier of
user B) to monitor the presence of user A. However, User B has two
(or more) IMPUs, and the one that is used (by user B) to monitor
the presence of user A is not the one that user A has authorised.
By conveying the grouping information for user B to network A so
that user B is able (using any of its IMPUs sharing the same
Service Profile) to monitor the presence of user A.
[0134] 2. Accept Reject Lists:
[0135] In for example push-to-talk-over-cellular (PoC), a
terminating PoC AS can access the accept and reject lists in the
XDMS for the terminating user in order to determine whether a
terminating PoC request can be terminated to a user. Hitherto, this
may not have worked properly in the case that a user can be
identified by more than one means (public user identifier). An
embodiment of the invention provides a solution to this problem by
including the grouping data in a SIP message that creates a new SIP
session (e.g. an INVITE). The semantics of such data could be "User
X is also known as {list of grouped public user identifiers}".
[0136] It will be appreciated by the person of skill in the art
that various modifications may be made to the above described
embodiments without departing from the scope of the present
invention.
* * * * *