WO2002019749A1

WO2002019749A1 - Extending sip for uploading subscriber's service profile from hss to cscf

Info

Publication number: WO2002019749A1
Application number: PCT/EP2000/008590
Authority: WO
Inventors: Krisztián KISS; Balázs BERTÉNYI
Original assignee: Nokia Corporation
Priority date: 2000-09-01
Filing date: 2000-09-01
Publication date: 2002-03-07
Also published as: AU2000275137A1

Abstract

The invention proposes a method for transmitting subscriber information from a first network element to a second network element, comprising the steps of inserting subscriber information in a specific message (1) of the same call control protocol that is used to establish the call; and sending the message from the first network element to the second network element. By this method, subscriber information can be easily uploaded from the first network element (e.g., a HSS) to the second network element (e.g., a CSCF). The invention also proposes a corresponding network system.

Description

"EXTENDING SIP FOR UPLOADING SUBSCRIBER'S SERVICE PROFILE

FROM HSS TO CSCF"

Field of the invention

The present invention relates to a method a network system for transmitting subscriber information from a first network element to a second network element.

BACKGROUND OF THE INVENTION

The present invention concerns the so-called subscriber profile. The subscriber profile holds subscription information about services and other parameters that have been assigned to a subscriber for an agreed contractual period. It includes information regarding subscribed services, subscribed QoS (Quality of Service) profile (i.e., service precedence (priority) , reliability, delay, throughput) etc. The data included in the subscriber profile are needed by the network element executing the service in order to handle the calls.

The subscriber profile includes for a given user, e.g., user identities, subscribed services and profiles, service specific information, mobility management information, authorization information etc.

In the 3GPP (Third Generation Partnership Project) Release 2000 (in the following referred to as R00) , this data are hold in the HSS (Home Subscriber Server) . Thus, the HSS is the master database for a given user. It is responsible for keeping a master list of features and services (either directly or via servers) associated with a user, and for tracking of location of and means of access for its users, i.e., provides the subscriber profile.

During normal calls, this subscriber profile is required by other network elements which handle the calls. Hence, the subscriber profile has to be conveyed to these other network elements.

Such a network element is a so-called Call State Control Function, for example. The CSCF is the call control entity in the all-IP architecture responsible for supervising the call (or IP multimedia call) . It handles the call establishment, supervision and disconnection signalling and may control resources associated with the call such as media gateways processing the various call related media streams .

A CSCF can fulfill different roles in an IP multimedia call signaling path, for example as a Serving CSCF (S- CSCF) , an Interrogating CSCF (I-CSCF) or an Originating CSCF (0-CSCF) , depending on which function it fulfills during a call.

The Serving CSCF supports the signalling interactions with the UE (User Equipment) , in particular, it provides a Serving Profile Database (SPD) described below. The Home Subscriber Server (HSS) is updated with the Serving CSCF address and the HSS sends the subscriber data to the Serving CSCF for storage .

The Interrogating CSCF (I-CSCF) is used for mobile terminated communications and is used to determine how to route mobile terminated calls. The Interrogating CSCF interrogates the HSS for information to enable the call to be directed to the Serving CSCF.

Moreover, an Originating CSCF (O-CSCF) is the CSCF where the originating party is registered and where the originating party services are handled. On the- other hand, the S-CSCF is the CSCF where the terminating party is registered and where the terminating party services are handled.

For mobile terminated communications both Serving CSCF and Interrogating CSCF functionality can be involved. For mobile originated communications Interrogating CSCF functionality is not required.

For controlling a call between the different CSCFs and the UE connected thereto, a call control protocol is required. One of such call control protocols is the so- called Session Initiation Protocol. In the following, some aspects of SIP are described in short.

SIP is a general-purpose tool for the initiation, modification, and termination of sessions. That is, SIP is an application-layer control (signalling) protocol that can establish, modify and terminate multimedia sessions or calls with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, multimedia distribution and similar applications. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. As a core part of its functionality, SIP carries the ports, IP addresses and domain names needed to describe the sessions it controls. SIP can be used to initiate sessions^' as well as to invite members to sessions that have been advertised and established by other means.

In the following, items concerning SIP are described which are necessary for understanding the present invention.

In SIP, a plurality of different requests are exchanged. A request is composed by a request line followed by a header and, optionally, a message body.

In the following, an example a for request is listed:

INVITE sip: UE (B) @HSS . ipt . operator . com SIP/2.0 Via: I-CSCF. ipt .operator . com From : UE (A)

To: UE (B) @ipt .operator . com Content-type: application/sdp Content-length: ...

The request line is made up as follows:

Request-Line = Method Request-URI SIP-Version

A method is a predefined procedure. Currently, in SIP the methods INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER are defined. For simplifying the description, only the methods INVITE and ACK are described in the following as examples in short . The INVITE method indicates that a user is being invited to participate in a sessions. Thus, the message body of a corresponding INVITE request contains a description of the session to which the callee is being invited.

The ACK method is used in the ACK request to confirm that a client has received a final response to an INVITE request. ACK is used only with INVITE requests. The ACK request may contain a message body with the final session description to be used by the callee. If the ACK message body is empty, the callee uses the session description in the INVITE request.

The request-URI is a SIP URL (Uniform Resource Locator) or a general URI (Uniform Resource Identifier) . It indicates the user or service to which this request is being addressed.

Furthermore, the request-line comprises the SIP version (e.g., SIP/2.0) in order to indicate the recipient which SIP version is used.

The header of the SIP request comprises a plurality of fields. In the following, only those fields are described in short which are important for the present embodiment.

A field "Via" indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unsusual routing situations. That is, each time a request is proxied, a new Via-field is added. A field "From" indicates the initiator of the request, whereas the field "To" indicates the recipient of the request .

A field "Content-Length" indicates the size of the message body, in decimal number of octets, sent to the recipient .

A field "Content-Type" indicates the media type of the message body sent to the recipient.

A field "Call-ID" uniquely identifies a particular invitation or all registrations of a particular client.

A field "CSeq" indicates a command sequence. It contains the request method (e.g., INVITE) and a single decimal sequence number chosen by the requesting client.

The message body comprises, for example, a description of the multimedia connection to which a recipient is invited. For example, the so-called Session Description Protocol (SDP) is used for this purpose.

On receiving a request, the recipient can send a response. For example, in case of an INVITE request, the recipient can agree to participating in the call by sending a so-called 200 OK response. A response is basically similar to a request, although the request-line is replaced by a status-line which in particular comprises a status code, which is in the above example 200. This value indicates OK. The header of a response can contain similar fields as the request. For example, in case of an 200 OK response to an INVITE request, the CSeq field contains the same value, e.g., INVITE 1. In Fig. 1, a basic example for network including the above-described network elements is shown. In detail, two User Equipments (UE) UE1 and UE2 , and a plurality of CSCFs are shown. O-CSCF and I-CSCF comprise a Subscriber Profile Database (SPD) and each CSCF comprises a SIP message processor for handling the SIP requests and responses. As mentioned above, whether a certain CSCF is an O-CSCF, an I-CSCF or an S-CSCF depends on the function the CSCF has to fulfill.

In this example, UE1 originates a call to UE2. Thus, the CSCF to which it is connected, is an O-CSCF. The O-CSCF forwards a call request to an I-CSCF which, in turn, tries to obtain the address of UE2 ' s S-CSCF by referring to an HSS. The I-CSCF obtains the address of the corresponding S-CSCF of UE2 and forwards the call thereto.

It is noted that in Fig. 1 the SPD in the O-CSCF and the S-CSCF has to interact with the HSS in the home domain to receive profile information for the R00 all-IP network user and store them. Furthermore, it notifies the home domain of initial user's access. In addition, it may cache access related information (e.g. terminal IP address (es) where the user may be reached etc.) .

In this example, only the I-CSCF has to access the HSS for obtaining information regarding the location etc. of UE2. Thus, the CSCF has to obtain a subscriber profile from a HSS in order to handle the call according to UE2 ' s services .

In R00, there is defined an interface Cx between the HSS and the CSCF. However, it is not defined yet how a subscriber profile can easily be uploaded from the HSS to an CSCF via this interface.

SUMMARY OF THE INVENTION

Therefore, the object underlying the invention resides in removing the above drawbacks of the prior art .

This object is solved by a method for transmitting subscriber information from a first network element to a second network element, comprising the steps of inserting subscriber information in a specific message of the same call control protocol that is used to establish the call; and sending the specific message from the first network element to the second network element.

In addition, the invention proposes a network system comprising a first network element and a second network element, wherein the first network element is adapted to insert subscriber information in a specific message of the same call control protocol that is used to establish the call, and to send the specific message to the second network element .

Thus, according to the invention the subscriber information are inserted in a specific message of the same call control protocol that is used to establish the call.

Therefore, according to the invention, an easy way of subscriber information uploading from one network element to another is provided. An advantage of the invention is that there is no need for an additional protocol for profile uploading purposes. That is, the same call control protocol used for other call control purposes in the network can be used. Thus, the system can be kept less complex.

In case the subscriber information have been received successfully by the second network element, a confirmation message may be sent from the second network element to the first network element. Thus, a successful uploading can easily be indicated to the first network element .

The call control message can be a PROFILE request based on the Session Initiation Protocol (SIP) , the subscriber information being inserted in the message body of the request. That is, according to the invention, a new SIP method for profile uploading purposes is introduced. Since SIP is already chosen as the call control protocol in R00, for example, no complex additional protocol is required, only an extended SIP (i.e., SIP including the new PROFILE request) is necessary.

The confirmation message is a SIP 200 OK message. In addition, the other SIP responses can be used to indicate failure situations.

The subscriber information can be a subscriber profile.

The first network element can be a Home Subscriber Server (HSS) and the second network element can be a Call State Control Function (CSCF) . Thus, the invention provides a protocol for conveying subscriber information via the Cx interface. The Call State Control Function (CSCF) may be a Serving Call State Control Function (S-CSCF) or an Interrogating Call State Control Function (I-CSCF) .

Alternatively, the first network element can be a Serving Call State Control Function (S-CSCF) and the second network element can be an Interrogating Call State Control Function (I-CSCF) . Thus, also uploading between two CSCFs is possible. This is advantageous during a dynamic CSCF selection, for example.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood with reference to the accompanying drawings in which:

Fig. 1 shows a network including UEs, CSCFs and HSS,

Fig. 2 shows a procedure for profile uploading according to an embodiment of the invention,

Fig. 3 shows a procedure for registration on network level according to the embodiment, and

Fig. 4 shows a procedure for call delivery according to the embodiment .

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

In the following, a preferred embodiment of the invention is described in more detail with reference to the accompanying drawings. In particular, according to the embodiment described below, uploading of a subscriber profile from a first network element, e.g., a Home Subscriber Server (HSS), to a second network element, e.g., a Call State Control Function (CSCF) is performed by using a specific call control protocol . This call control protocol is preferably also used in the network for other purposes.

In this embodiment, the Session Initiation Protocol (SIP) is used as the call control protocol.

According to the present embodiment, SIP is extended for uploading subscribers' service profile from HSS to CSCF.

That is, according to the embodiment a new SIP method for profile downloading is introduced, which is referred to as the SIP PROFILE method in the following

It should always be the HSS who initiates the PROFILE request, this request should contain the subscriber profile data. The CSCF should respond to the request in successful case with a 200 OK.

There are several alternatives for subscriber profile data representation conveyed in the PROFILE request, e.g. XML (eXtendend Markup Language) , HTML (Hyper Text Markup Language) . In the present embodiment, HTML is used for profile data representation.

Fig. 2 shows the profile uploading using the newly introduced PROFILE method. In step 1, the PROFILE request is sent to the CSCF, and the CSCF answers with a 200 OK response in case the subscriber profile was successfully received. In the following, a PROFILE request including the new PROFILE method is listed:

PROFILE sip: CSCF. ipt.operator.com SIP/2.0 Via: HSS.ipt.operator.com From : UE@HSS . ipt . operator . com To: UE@ipt.operator.com Call -ID : 123456@HSS . ipt . operator . com Cseq: 1 PROFILE

Content-type: text/html Content-length: ...

That is, by the new PROFILE method, the subscriber profile is inserted in the message body. Hence, only this one message 1 (i.e., the PROFILE request) is necessary to transmit the subscriber profile to the CSCF.

In case the message 1 was received successfully, the CSCF answers with a 200 OK response as follows:

2. SIP/2.0 200 OK

Via: HSS.ipt.operator.com

From : UE@HSS . ipt . operator . com

To : UE@ipt . operator . com

Call-ID: 123456@HSS. ipt.operator.com Cseq: 1 PROFILE

Content-length : 0 Thus, if the HSS receives a 200 OK response, it knows immediately that the subscriber profile was successfully transmitted.

The profile uploading as mentioned above is basically needed in two major scenarios: registration and mobile terminated call delivery.

Next, these two scenarios are described with reference to Figs. 3 and 4.

Fig. 3 illustrates a registration procedure of a User Equipment UE .

In message Al, a SIP REGISTER request is sent from the UE to the S-CSCF. The REGISTER request is used in order to register an address listed in the To header field with a SIP server.

That is, the meaning of the header fields is defined slightly different from those of, e.g., the INVITE request. In detail, the To header field contains the address whose registration is to be created (or updated) . The From header field contains the address of the person (or entity) responsible for the registration. Since these addresses are not used in the way as they are in other request types (e.g., the INVITE request), they are referred to as "address-of-record" . The Request-URI (included in the request-line) names the destination of the registration request, i.e., the domain of the registrar.

In the procedure illustrated in Fig. 3, message Al is a SIP REGISTER request. This message is received by the S- CSCF. Al. REGISTER sip : S-CSCF. ipt . operator. com SIP/2.0

Via: ab.cd.de: : 11.11 //UE's IP-address

From: UE@ipt . operator . com To: UE@ipt.operator.com

In order to perform the requested registration of the UE, the S-CSCF has to know the subscriber profile. Hence the REGISTER request has to be forwarded to the HSS. The S- CSCF finds the domain name of HSS based on the value of the To header. S-CSCF proxies the REGISTER message further towards the HSS in message A2.

A2. REGISTER sip :HSS . ipt . operator . com SIP/2.0

Via: S-CSCF. ipt .operator .com

Via: ab.cd.de: .-11.11

From: UE@ipt.operator.com

To : UE@ipt . operator . com

Thereafter, the HSS performs profile downloading with the S-CSCF. This is effected as described above.

That is, the subscriber profile is immediately inserted in a PROFILE request which is sent to the S-CSCF in A3. This is performed as described above with respect to Fig. 2. That is, the PROFILE request is sent from the HSS to the S-CSCF which responds with a 200 OK response.

On receiving the 200 OK message from the S-CSCF, the HSS knows that the subscriber profile downloading was successful and sends itself a 200 OK message A4 to the S- CSCF. A4 . SIP/ 2 . 0 200 OK

Via: S-CSCF. ipt .operator. com Via: ab.cd.de: :11.11 From : UE@ipt . operator . com To: UE@ipt.operator.com Cseq: 1 REGISTER

This message is forwarded to the UE in message A5.

A5. SIP/2.0 200 OK

Via: ab.cd.de: : 11.11 From: UE@ipt.operator.com To: UE@ipt.operator.com CSeq: 1 REGISTER

After this message, the registration procedure has been successfully completed.

Next, as a further example where the profile downloading according to the present embodiment can be used, a call delivery is described below with respect to Fig. 4.

It is noted that here, REP (Remote Endpoint) represents the originating side of the call, e.g., a UE (A) and an 0- CSCF together.

In a first message Bl, an INVITE request is sent from the REP to the interrogating CSCF, i.e., the I-CSCF. Bl. INVITE sip:UE(B)@I-CSCF. ipt.operator.com SIP/2.0 Via: REP From: UE(A)

To: UE (B) @ipt . operator . com Content-type: application/sdp Content-length: ...

In message B2 , the I-CSCF proxies the INVITE message to the HSS.

B2. INVITE sip:UE(B)@HSS. ipt .operator.com SIP/2.0 Via: I-CSCF. ipt .operator . com

Via: REP

From: UE(A)

To: UE (B) @ipt .operator . com

Content-type : application/sdp Content-length: ...

In this case, the HSS gives the answer that UE(B) has temporarily moved by responding with a 302 Moved Temporarily Response in message B3.

B3. SIP/2.0 302 Moved temporarily Via: I-CSCF. ipt .operator .com Via: REP From : UE (A) To: UE (B) @ipt .operator .com

This request comprises a header field "Contact" which indicates a URL or URI where the user can be reached for further communications.

Thereafter, the I-CSCF sends an acknowledgment ACK request to the HSS in message B4.

B4. ACK sip :UE(B)@HSS. ipt .operator.com SIP/2.0 Via: I-CSCF. ipt . operator . com From: UE (A)

To: UE (B)@ipt. operator .com

At this point the HSS may initiate a profile uploading with the I-CSCF, if service control mechanism also resides in the I-CSCF. This is performed as described above with respect to Fig. 2. That is, the PROFILE request is sent from the HSS to the I-CSCF which responds with a 200 OK response.

Then, the I-CSCF proxies the INIVITE message to the S- CSCF in message B6. B6. INVITE sip:UE(B)@S-CSCF. ipt. operator. com SIP/2.0 Via: I-CSCF. ipt .operator . com Via: REP From: UE (A)

To: UE (B) @ipt .operator . com Content-type : application/sdp Content-length: ...

Thereafter, a regular call setup is continued. Thus, a detailed description of the following messages is omitted.

In message B7 , the INVITE request is transmitted to the UE(B), which acknowledges the INVITE request with a 200 OK response in message B8. This 200 OK message is forwarded to the REP (i.e., the UE (A) ) in messages B9 and B10. Finally, UE (A) acknowledges the OK of UE (B) by sending an ACK request to UE(B) in messages Bll to B13. Thereafter, the multimedia session can begin.

With respect to the profile downloading in this case (i.e., message B5) , it is noted that in this case in particular the location information included in the subscriber profile is important. For example, maybe user UE(B) is not entitled to use his mobile station in the location where he currently is. Since the subscriber profile can basically divided in location (routing) information and service profile, it would also be sufficient in this case when only the location information (and/or service information which is location depending) is mandatorily downloaded to the I-CSCF. As mentioned above, the representation of the subscriber profile in HTML is only an example, and, as ^"a matter of course, other appropriate representations can be used.

The service profile part of the subscriber profile itself depends on the service execution architecture to be adopted in 3GPP for R00. Basically, there are three possibilities: CAMEL (Customized Applications for Mobile network Enhanced Logic) , SIP and OSA (Open Service Architecture) .

The OSA (Open Service Architecture) defines an open API (Application Programming Interface) for the design, implementation, control and execution of services and applications provided by third party service providers.

In case CAMEL is used for the service profile, then CSI (CAMEL Subscriber Information) using ASN.l representation is utilized for representing the service profile.

In SIP, the service profile can be a script written in a script language, which may be, e.g., a common script language like Call Processing Language (CPL) , Common Gateway Interface (CGI) or Java Enhanced SIP (JES) .

In case of OSA, any of the above described service profiles can be used in an appropriate way.

The above description and accompanying drawings only illustrate the present invention by way of example. Thus, the embodiment may vary within the scope of the attached claims .

Claims

1. A method for transmitting subscriber information from a first network element to a second network element, comprising the steps of inserting subscriber information in a specific message (1) of the same call control protocol that is used to establish the call; and sending the message (1) from the first network element to the second network element .

2. The method according to claim 1, further comprising the step of sending a confirmation message (2) from the second network element to the first network element in case the subscriber information have been received successfully by the second network element .

3. The method according to claim 1, wherein the call control message is a PROFILE request based on the Session Initiation Protocol (SIP) , the subscriber information being inserted in the message body of the request .

4. The method according to claim 2, wherein the call control message is a PROFILE request based on the Session Initiation Protocol (SIP) , the subscriber information being inserted in the message body of the request, and the confirmation message (2) is a SIP 200 OK message.

5. The method according to claim 1, wherein the subscriber information is a subscriber profile.

6. The method according to claim 1, wherein the first network element is a Home Subscriber Server (HSS) and the second network element is a Call State Control Function (CSCF) .

7. The method according to claim 6, wherein the Call State Control Function (CSCF) is a Serving Call State

Control Function (S-CSCF) .

8. The method according to claim 6 , wherein the Call State Control Function (CSCF) is an Interrogating Call State Control Function (I-CSCF) .

9. The method according to claim 1, wherein the first network element is a Serving Call State Control Function

(S-CSCF) and the second network element is an Interrogating Call State Control Function (I-CSCF) .

10. A network system comprising a first network element and a second network element, wherein the first network element is adapted to insert subscriber information in a specific message (1) of the same call control protocol that is used to establish the call, and to send the message (1) to the second network element .

11. The network system according to claim 10, wherein the second element is adapted to send a confirmation message (2) to the first network element in case the subscriber information have been received successfully by the second network element .

12. The network system according to claim 10, wherein the call control message is a PROFILE request based on the Session Initiation Protocol (SIP) , the subscriber information being inserted in the message body of the request.

13. The network system according to claim 11, wherein the call control message is a PROFILE request based on the Session Initiation Protocol (SIP) , the subscriber information being inserted in the message body of the request, and the confirmation message (2) is a SIP 200 OK message .

14. The network system according to claim 10, wherein the subscriber information is a subscriber profile.

15. The network system according to claim 10, wherein the first network element is a Home Subscriber Server (HSS) and the second network element is a Call State Control Function (CSCF) .

16. The network system according to claim 15, wherein the Call State Control Function (CSCF) is a Serving Call State Control Function (S-CSCF) .

17. The network system according to claim 15, wherein the Call State Control Function (CSCF) is an Interrogating Call State Control Function (I-CSCF) .

18. The network system according to claim 10, wherein the first network element is a Serving Call State Control Function (S-CSCF) and the second network element is an Interrogating Call State Control Function (I-CSCF) .