Patent Application
20080254791
The present invention relates generally to communications systems and in particular to methods and systems associated with IP Multimedia Subsystem (IMS) architectures.
As the level of technology increases, the options for communications have become more varied. For example, in the last 30 years in the telecommunications industry, personal communications have evolved from a home having a single rotary dial telephone, to a home having multiple telephone, cable and/or fiber optic lines that accommodate both voice and data. Additionally cellular phones and Wi-Fi have added a mobile element to communications. Similarly, in the entertainment industry, 30 years ago there was only one format for television and this format was transmitted over the air and received via antennas located at a home. This has evolved into both different standards of picture quality such as, standard definition TV (SDTV), enhanced definition TV (EDTV) and high definition TV (HDTV), and more systems for delivery of these different television display formats such as cable and satellite. Additionally, services have grown to become overlapping between these two industries. As these systems continue to evolve in both industries, the service offerings will continue to merge and new services can be expected to be available for a consumer. Also these services will be based on the technical capability to process and output more information, for example as seen in the improvements in the picture quality of programs viewed on televisions, and therefore it is expected that service delivery requirements will continue to rely on more bandwidth being available throughout the network including the “last mile” to the end user.
Another related technology that impacts both the communications and entertainment industries is the Internet. The physical structure of the Internet and associated communication streams have also evolved to handle an increased flow of data. Servers have more memory than ever before, communications links exist that have a higher bandwidth than in the past, processors are faster and more capable and protocols exist to take advantage of these elements. As consumers' usage of the Internet grows, service companies have turned to the Internet (and other IP networks) as a mechanism for providing traditional services. These multimedia services can include Internet Protocol television (IPTV, referring to systems or services that deliver television programs over a network using IP data packets), video on demand (VOD), voice-over-IP (VoIP), and other web related services.
To accommodate the new and different ways in which IP networks are being used to provide various services, new network architectures are being developed and standardized. One such development is the Internet Protocol Multimedia Subsytem (IMS) architecture. IMS is an architectural framework which uses a plurality of Internet Protocols (IP) for delivering IP multimedia services to an end user. A goal of IMS is to assist in the delivery of these services to an end user by having a horizontal control layer which separates the service layer and the access layer. More details regarding IMS architectures and various entities associated therewith are provided below.
One aspect of IMS architecture of particular interest for this application is that it has been created, as specified in the standards document 3GPP TS 23.228 IP “Multimedia Subsystem (IMS); Stage 2”, Version 8, March 2007, available for download at: http://www.3gpp.org/ftp/Specs/archive/23_series/23.228/, based on the premise that services would be sent for execution to the home domain mobile operator of a subscriber. As shown in
However, requiring that the HSS 18 and I-CSCF 12, S-CSCF 14 be located within the same domain (e.g., home domain 16 which is owned or managed by the same company) limits the flexibility with which, for example, operators can structure their businesses. Additionally, since it has previously been assumed that the HSS 18 will also be located in the same domain as the Home Location Register (HLR, not shown in
More specifically, an SMS message is preferably delivered where the dual-mode (i.e., Circuit Switched (CS) and IMS) user is currently attached, also taking into account operator and/or user preferences when the user is attached or registered in both CS domain and IMS domain simultaneously. Note that the CS domain components are not illustrated in
Accordingly, it would be desirable to provide methods and systems for permitting the HSS to be located in a domain other than that in which the I-CSCF, S-CSCF and/or HLR are located to provide for a more flexible system architecture and to facilitate bi-directional SMS messaging.
According to an exemplary embodiment, a communication system includes a proxy node including a processor for running an inter-domain application which provides functionality associated with a corresponding non-proxy node, which functionality includes a set of interfaces.
According to another exemplary embodiment, a method for registering in an IP Multimedia Subsystem (IMS) communication system includes the steps of: receiving, at a home subscriber service (HSS) proxy entity, an IMS registration information flow, forwarding, by the HSS proxy entity, the IMS registration information flow to an HSS node via an inter-domain protocol server, and returning IMS registration information from the HSS node.
According to another exemplary embodiment, a method for exchanging information between a home subscriber services (HSS) proxy node and a home location register (HLR) includes the steps of: connecting the HSS proxy node to a inter-domain protocol server, connecting the HLR to the inter-domain protocol server, and exchanging the information via the inter-domain protocol server.
According to still another exemplary embodiment, a home location register (HLR) includes a memory device for storing user data, wherein the HLR receives, and stores in the memory, short message service (SMS) routing information when a user connects to an IP Multimedia Subsystem (IMS) communication system from a Repository Access Function (RAF).
According to yet another exemplary embodiment, a method for providing an inter-domain, IP Multimedia System (IMS) service includes the steps of providing a first domain having a first set of IMS communication nodes, providing a second domain having a second set of IMS communication nodes, and providing the inter-domain, IMS service between the first domain and the second domain, wherein one of the IMS communication nodes disposed in the first domain stores a set of subscriber data used to provide the inter-domain, IMS service, and further wherein one of the IMS communication nodes disposed in the second domain stores a subset of the subscriber data used to provide the inter-domain IMS service.
The accompanying drawings illustrate exemplary embodiments, wherein:
The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
In order to provide some additional context for this discussion, a brief discussion regarding the manner in which user equipment (UE) 22 of
Assuming that the user equipment 22 is authorized to register in the visited network, I-CSCF 12 will then continue the registration process by sending the registration message to the selected S-CSCF 14 as signal 5. The selected S-CSCF 14, in turn, sends a Cx-Put/Pull message to the HSS 18 as signal 6, including the public/private user identity associated with user equipment 22 and its S-CSCF name. The HSS 18 stores the received session information and returns, via signal 7, user information to the S-CSCF 14 including, for example, information usable to access service control platforms(s) while this particular user is registered at this S-CSCF 14. As indicated by step 8, the SCSF 14 can then send registration information to the service control platform(s) (not shown) and perform service control functions, as needed. Acknowledgement of the successful registration is returned through the IMS network to the UE 22 via signals 9-11.
As mentioned above, it would be desirable to provide more flexibility to the network architecture than is currently available in IMS systems wherein the HSS 18 is co-located with (e.g., in the same domain as), for example, the I-CSCF 12 and S-CSCF 14. Thus, according to exemplary embodiments, an HSS Proxy 30 can be provided as shown in the system of
According to these exemplary embodiments, the HSS Proxy 30 is intended to operate in much the same way as the HSS 40, but allows all or part of the HSS 40 to be located within, e.g., the mobile operator domain, instead of, e.g., a 3rd party's IMS domain. In particular, it may be desirable to provide for all or part of the user data associated with the HSS entity to be located within one domain, while providing a proxy in another domain(s) that satisfies the standardized functionality for the HSS. Thus, the HSS Proxy 30 will have a plurality of interfaces available for the nodes which expect to connect to HSS 40, e.g., a first Cx interface for connecting the HSS Proxy 30 to the I-CSCF 32, a second Cx interface for connecting the HSS Proxy 30 to the S-CSCF 34 and an Sh interface for connecting the HSS Proxy 30 to the IMS AS 36. As mentioned earlier, the Cx and Sh interfaces are further described in 3GPP TS 23.228 IP “Multimedia Subsystem (IMS); Stage 2”, Version 8, March 2007. For example, the Cx interface is a local domain's data exchange interface. The Sh interface is an interface which transports transparent data associated with, e.g., service related data and user related information. Among other things, these features of HSS Proxy 30 according to this exemplary embodiment provide for the delivery of services across domains (such as multiple operators) without requiring that the subscriber data reside in both entity networks.
In order to act as a proxy for the actual HSS 40, HSS Proxy 30, according to this exemplary embodiment, can be a server running an HSS proxy application which operates as a Generic User Profile (GUP) application and, therefore, supports an Rg reference point protocol interface to a GUP server 42. The Rg reference point interface is provided to control the data stored in the different GUP components associated with GUP server 42, which components are identified by a resource identity and the component type. GUP architectures and applications address issues associated with the distribution of data associated with a user across various domains within, e.g., a 3GPP mobile system. Thus, the 3GPP GUP standards document, promulgated by 3GPP as TS 23.240 (3GPP Generic User Profile (GUP); Architecture (Stage 2)), Release 6, v. 6.7.0, March 2005, available for download at: http://www.3gpp.org/ftp/Specs/archive/23_series/23.240/, the disclosure of which is incorporated here by reference, provides an architecture, data description and interface with mechanisms to address these data handling issues. The GUP server 42 interfaces with the HLR 38 and the HSS 40 via Rp reference point interfaces and Repository Access Functions (RAFs) 44 and 46, respectively. The RAFs 44 and 46 provide protocol and data transformation into the GUP infrastructure.
User equipment (UE) 48 connects through to its home (e.g., mobile operator) domain via P-CSCF/SBG 50 from a visited network. Registration of the user equipment 48 in systems using an HSS Proxy 30 can be performed according to exemplary embodiments as shown in the signaling diagram of
Upon receipt, the HSS 40 stores the S-CSCF name associated with the user equipment 48 and returns the information flow 408 to that S-CSCF 34 including information which can be used to access platform(s) for service control and security information. The information flow 408 is received by the RAF 46 and converted into a Deliver GUP Data Element or Component message 410. Message 410 is sent to the GUP server 42, via the Rp reference point interface, and forwarded onto the HSS proxy 30 via the Rg reference point interface. The HSS proxy 30 transforms the message 410 into an IMS Cx Query Response message 412 which, for example, includes the access platform address information and/or security information provided by HSS 40. The I-CSCF 32 forwards an acknowledgement signal back through P-CSCF/SBG 50 to the user equipment 48 indicating that registration has been successful.
Thus, the foregoing registration process illustrates how an HSS Proxy 30 according to these embodiments provides a transparent mechanism (from the point of view of the other IMS entities) for providing HSS functionality within a first domain, while actually locating the HSS database within a second, different domain (i.e., an inter-domain HSS). The HSS Proxy 30 may operate as a pass-through mechanism which does not store any user data itself but simply passes information flows to and from the HSS 40. Alternatively, the HSS Proxy 30 may, according to some exemplary embodiments, operate as a subtending HSS which accesses or stores a subset of the data which is stored in the HSS 40 to allow a secondary carrier/operator to directly provide services offered by a main carrier/operator, while still providing the main carrier/operator with ownership and control over the complete HSS 40's database.
This technique according to exemplary embodiments of splitting entities in a manner which enables data sets and/or associated functionality to be flexibly positioned in any desired domain is not limited to HSS functionality and data. For example, as briefly mentioned above, according to another exemplary embodiment the database associated with IMS AS 36 may also be removed from the domain containing, e.g., the I-CSCF 32 and S-CSCF 34, and disposed in the same domain as the HLR 38 and HSS 40. This can be accomplished by, as shown in the exemplary embodiment of
The IMS AS Proxy 58 thus may operate as a pass-through mechanism which does not store any application service data itself but simply passes information flows to and from the IMS AS (database) 36. Alternatively, the IMS AS Proxy 58 may, according to some exemplary embodiments, operate as a subtending IMS AS which accesses or stores a subset of the data which is stored in the IMS AS database 36 to allow a secondary carrier/operator to directly provide services offered by a main carrier/operator, while still providing the main carrier/operator with ownership and control over the complete IMS AS 36's database. Additionally, IMS Proxy 58 can be provided in systems with do not employ an HSS Proxy 30. More generally, any IMS communication node can be partitioned into a proxy node and a non-proxy node using the afore-described techniques. Such a proxy communication node can, for example, include a processor running a GUP application which provides services which are a subset of those services provided by the corresponding non-proxy node. In some cases the subset can be quite limited, e.g., a corresponding set of interfaces to other communication nodes which expect to be able to connect with the non-proxy node. In other cases the subset can be more substantial, e.g., including a reduced data set and/or application functionality set.
The exemplary architectures illustrated in
As shown in
Some of the communication nodes described above, e.g., the HSS proxy node, IMS AS proxy node, etc., may be implemented as servers. For example, as shown generally in
In the foregoing exemplary embodiments, GUP applications, servers and interfaces have been described for facilitating communications between proxy nodes and corresponding non-proxy nodes. However, those skilled in the art will appreciate that other appropriate inter-domain protocols or applications can be used as alternatives to GUP, e.g., AAA protocols such as DIAMETER or RADIUS. Thus, according to exemplary embodiments, a proxy node can include a processor for running an inter-domain application, e.g., a GUP application, which provides functionality associated with a corresponding non-proxy node, that functionality including a set of interfaces, e.g., to support operation as an HSS proxy node or an IMS AS proxy node.
The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items.
