BLAU, Staffan (Tallstubbsbacken 1, Spågna, S-163 54, SE)
FALKENÅ, Jonas (Köpmansvägen 28, Huddinge, S-141 43, SE)
STILLE, Mats (Alstensgatan 33, Bromma, S-167 65, SE)
BLAU, Staffan (Tallstubbsbacken 1, Spågna, S-163 54, SE)
FALKENÅ, Jonas (Köpmansvägen 28, Huddinge, S-141 43, SE)
| CLAIMS: 1. A method of controlling the provision of IP Multimedia Subsystem, IMS, services between first and second IMSs operated by first and second different respective operators, the method comprising at a border control function between the first and second IMSs: (a) maintaining a store of information relating to a plurality of service agreements reached between the first and second operators, the service agreements relating to respective services provided between the first and second IMSs; (b) receiving a message relating to a service; (c) determining with reference to the store of information the extent to which the service is an allowed service; and (d) processing the message in dependence upon the determination. 2. A method as claimed in claim 1 , wherein the message received in step (b) comprises a service request message. 3. A method as claimed in claim 2, wherein step (d) comprises allowing or disallowing the requested service in dependence upon the determination made in step (C). 4. A method as claimed in claim 2 or 3, wherein the service request message comprises a SIP service request message, and wherein step (c) comprises using the Accept-Contact header of the SIP service request message to identify the service. 5. A method as claimed in any preceding claim, wherein the message received in step (b) comprises a Presence notification message, and wherein step (c) comprises determining from the store which parts of the Presence information being notified are allowed. 6. A method as claimed in claim 5, wherein step (d) comprises filtering out those parts of the Presence information not allowed and forwarding those parts that are. 7. A method as claimed in claim 5 or 6, wherein the Presence notification message comprises a SIP NOTIFY message. 8. A method as claimed in any preceding claim, comprising using a feature tag according to RFC 3840/41 to identify the service. 9. A method as claimed in any preceding claim, wherein the border control function is a 3GPP Interconnection Border Control Function, IBCF. 10. An apparatus for use as or in a border control function between first and second IP Multimedia Subsystems operated by first and second different respective operators, the apparatus comprising: (a) means for maintaining a store of information relating to a plurality of service agreements reached between the first and second operators, the service agreements relating to respective services provided between the first and second IP Multimedia Subsystems; (b) means for receiving a message relating to a service; (c) means for determining with reference to the store of information the extent to which the service is an allowed service; and (d) means for processing the message in dependence upon the determination. 1 1. A program for controlling an apparatus to perform a method as claimed in any one of claims 1 to 9. 12. A program as claimed in claim 11 , wherein carried on a carrier medium. 13. A program as claimed in claim 12, wherein the carrier medium is a storage medium. 14. A program as claimed in claim 12, wherein the carrier medium is a transmission medium. 15. A storage medium containing a program as claimed in any one of claims 1 1 to 14. |
Technical field
The present invention relates to a method and apparatus for use in a communications network, for example a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.
Background
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP
TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329
Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated
Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). 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. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
In a situation where two IMS operators cooperate to provide a service to a user, an interconnect agreement would be in place between the two IMS operators to enable that cooperation. Incoming IMS border gateway control functions validate the originating operator address domain against a white-list of IMS inter-connected operators to determine whether the communication can be allowed.
The pace with which operators will launch IMS enabled services will differ from operator to operator. When two operators launch the same IMS service they will typically set up an IMS interconnect agreement. However, a problem arises when one of the two operators launches further IMS services going beyond the original service, whilst the other operator is still operating the original one. Another problem arises where both operators launch the same or similar next-generation service without having decided yet on whether they should allow inter-connect with each other for this new service.
Such a situation could well lead to long-lasting negotiations between the two operator companies, and until those negotiations are settled, a significant technical problem arises because no interconnect traffic can be allowed.
It is desirable to address this issue. Summary
According to a first aspect of the present invention there is provided a method of controlling the provision of IP Multimedia Subsystem, IMS, services between first and second IMSs operated by first and second different respective operators, the method comprising at a border control function between the first and second IMSs: (a) maintaining a store of information relating to a plurality of service agreements reached between the first and second operators, the service agreements relating to respective services provided between the first and second IMSs; (b) receiving a message relating to a service; (c) determining with reference to the store of information the extent to which the service is an allowed service; and (d) processing the message in dependence upon the determination.
The message received in step (b) may comprise a service request message.
Step (d) may comprise allowing or disallowing the requested service in dependence upon the determination made in step (c).
The service request message may comprise a SIP service request message, and step (c) may comprise using the Accept-Contact header of the SIP service request message to identify the service.
The message received in step (b) may comprise a Presence notification message, and step (c) may comprise determining from the store which parts of the Presence information being notified are allowed.
Step (d) may comprise filtering out those parts of the Presence information not allowed and forwarding those parts that are.
The Presence notification message may comprise a SIP NOTIFY message.
The method may comprise using a feature tag according to RFC 3840/41 to identify the service. The border control function may be a 3GPP Interconnection Border Control Function, IBCF.
According to a second aspect of the present invention there is provided an apparatus for use as or in a border control function between first and second IP Multimedia Subsystems operated by first and second different respective operators, the apparatus comprising: (a) means for maintaining a store of information relating to a plurality of service agreements reached between the first and second operators, the service agreements relating to respective services provided between the first and second IP Multimedia Subsystems; (b) means for receiving a message relating to a service; (c) means for determining with reference to the store of information the extent to which the service is an allowed service; and (d) means for processing the message in dependence upon the determination.
The border control function above need not be physically located between the two IMSs but need only act in some function as a pass-through for certain communications between the two IMSs. The border control function above may in fact be any suitable node, and not necessarily one having a border control function, and may in fact be located clearly within one or other of the IMSs rather than being considered as situated at or near a border between the IMSs. For example, the "border control function" above should read as including such nodes as a Presence server, at least in the case where the service relates to the provision of Presence information.
According to a third aspect of the present invention there is provided a program for controlling an apparatus to perform a method according to the first aspect of the present invention or which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the second aspect of the present invention. The program may be carried on a carrier medium. The carrier medium may be a storage medium. The carrier medium may be a transmission medium.
According to a fourth aspect of the present invention there is provided an apparatus programmed by a program according to the third aspect of the present invention.
According to a fifth aspect of the present invention there is provided a storage medium containing a program according to the third aspect of the present invention. Brief description of the drawings
Figure 1 is a flowchart illustrating a method according to an embodiment of the present invention; and
Figure 2 is a schematic block diagram illustrating an apparatus according to an embodiment of the present invention.
Detailed description
An embodiment of the present invention will now be described with reference to the flowchart of Figure 1 and with reference to the schematic block diagram of Figure 2.
It has been mentioned above that the problem of potential gaps in service while interconnect agreements are being settled by two operator companies. A solution according to an embodiment of the present invention is to have a white-list function at the incoming border control function of an IMS network, known as an Interconnection Border Control Function (IBCF) in 3GPP terminology, that is based on IMS services rather than (or in addition to) being based on IMS operators.
In this respect, the present applicant has appreciated that the above-mentioned technical problem revolves around the fact that there is currently no assumption that it is necessary to have an IMS-service agreement within that IMS inter-connect agreement. A solution according to an embodiment of the present invention allows an IMS inter-connect agreement to be maintained between two operators for some IMS services but not for other IMS services.
In an embodiment of the present invention, the IBCF would have the standard white- list, with the respective addresses of the operators with whom there is an IMS interconnect agreement. Beyond this, however, the IBCF (or other node at the discretion of the local implementation) would have a white-list on a per-IMS-service basis. An IMS service is identified by a feature tag (RFC 3840/41 ). This is included in the Accept-Contact header of the initial SIP message that is sent when the IMS-service is invoked. The identifier is unique as per IMS service, and is normally described in the specification of the IMS service in particular.
For example, the IMS service 'Messaging' (by OMA IM) is identified by a feature tag +g.oma.sip-im, while the IMS service 'push-to-talk' is identified by a feature tag +g.poc.talkburst.
Where operator A and B have a basic IMS interconnect agreement and moreover specifically a messaging and push-to-talk IMS services agreements, the above two mentioned feature tags would be stored in a tag store P6 in the IBCF.
In step S1 , a receiving portion P1 of an operator's IBCF receives an initial SIP message (such as a SIP INVITE message) from another operator with whom there is an IMS subscription. In step S2, a tag identification portion P2 of the IBCF identifies the requested service with reference to the tag included in the SIP message. In step
S3, a look-up portion checks the service identity tag carried in the Accept-contact header against a white-list of agreed services in the tag store P6, and a decision portion P5 determines whether or not the requested service is an allowed service based on the look-up.
Thus, if the SIP INVITE message looks like this:
INVITE
Accept-contact: * ;+g.oma.sip-im
Then the IBCF treats it as allowed for further processing in the IMS core network (step S4), due to it finding a matching result in the IMS services whitelist for "+g.oma.sip-im".
But, suppose now that the received SIP INVITE message from an IMS inter-connected operator looks like this:
INVITE Accept-contact: * ; +g.3gpp.icsi_ref:"urn.3gpp. service, ims.icsi.mmtel" In this example, the IBCF will find a match for the operator address but will find a non- match on the IMS service, because "+g.3gpp.icsi_ref:"urn.3gpp. service. ims.icsi.mmtel"" is a feature tag that is not in the IMS service white-list data store of the IBCF. The decision portion P5 of the IBCF then rejects the INVITE e.g. with SIP 403 Forbidden message sent by the sending portion P4, and possibly a Reason header with "service not allowed" to make it clear to the originating operator what the reason for failure was.
In this example, the reason why the IBCF does not have the service identity +g.3gpp.icsi_ref:"urn.3gpp. service. ims.icsi.mmtel" in its data store could be either that the operator has not launched the service among his own subscribers, or that the operator do have launched the same service, but is yet in termination fee agreements negotiations with the inter-connected IMS operator with will take months to settle.
Besides communication services like IM and MMtel described above, two operators could have an inter-connect agreement on an IMS based information service like OMA Presence. This allows a subscriber (watchers in Presence terminology) belonging to operator A to receive capability and personal information about buddies (Presentities in Presence terminology) belonging to operator B. However, just because there is a Presence agreement it would not necessarily mean that all presence data attributes are agreed on. For this reason, operator B could have a service data filter set up with operator A. This filter may be configured to discard for example the 'note' tuplet (free text) or capability information ('service-id' tuplet in Presence terminology). The filter would be activated every time there is an incoming Presence notification (SIP NOTIFY) received from another IMS network with which there is a Presence agreement, and/or when there are outgoing Presence notifications destined other networks with which there is a Presence service agreement. It should be noted that the service data filtering need not be handled by the IBCF, but may in another embodiment be handled for example by a server inside the receiver network (such as the Presence server).
It will be appreciated that, while the above description refers to the maintaining of a white-list showing all allowed services, a black-list could be maintained instead of or as well as the white-list. The black-list would indicate those services that are specifically not allowed. It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.
Next Patent: MOVABLE WIND DEFLECTOR