Abstract:
The invention relates to a method of enabling use equipment to establish a communication session over an IMS network. The communication session is enabled by one or more call/session control functions in the network in accordance with media characteristics that define the network resources to be utilised for the session. The method comprises: receiving with the IMS network a subscriber registration request originating from the user equipment and, in response thereto, sending to the user equipment an identification of allowable media characteristics.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to a method and apparatus for improving the way in which User Equipment (UE) establishes a multimedia session in an IP Multimedia Subsystem (IMS) network. 
       BACKGROUND 
       [0002]    The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services. 
         [0003]    The 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 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. 
         [0004]      FIG. 1  illustrates schematically how the IMS  2  fits into the mobile network architecture in the case of a GPRS/PS access network. The IMS  2  includes a core network  2   a  and a service network  2   b.  Call/Session Control Functions (CSCFs)  4  operate as SIP proxies within the IMS  2 . 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. In addition the IMS network includes a Home Subscriber Server (HSS)  6 . The HSS  6  is the master user database that supports the IMS network entities. It contains subscription-related information and credentials for further authentication and authorisation of users. 
         [0005]    A user registers with 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. The user receives a unique URI (Uniform Resource Indicator) from the S-CSCF for it to use when it initiates a dialog. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates an S-CSCF to that user from the set of available S-CSCFs. When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides of the IMS (for the terminating call the request will include the P-CSCF address and the UE address). 
         [0006]    Within the IMS service network  2   b,  Application Servers (ASs)  8  are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). 
         [0007]    When a subscriber&#39;s user equipment (UE), such as a mobile telephone or computer, registered with the IMS, wishes to initiate a multimedia session it sends a session request, which, for example, may be in the form of a SIP INVITE message. Within the session request, the SDP includes details of the type of session requested, which includes the different media (e.g. audio, video etc.) as well as information referred to hereafter as media characteristics that the UE is capable of handling. The media characteristics may include, for example, information about the codec (compression-decompression) procedures that the UE supports as well as the processing rates (kbps) of the codecs. 
         [0008]    3GPP technical specification TS 23.228 [1] defines procedures for determining (negotiating) the codec and media characteristics between the endpoints of a multi-media session during the initial session set-up and for making subsequent modifications. These procedures run end-to-end between the two communicating peers although, as defined by 3GPP, the S-CSCF and P-CSCF at either side of the communication path have the ability to influence such negotiation. In the event that any of the S-CSCFs and/or P-CSCFs in the communication path finds that the session request includes media parameters that are not allowed within an IMS session, they shall reject the session initiation attempt. 
         [0009]    The S-CSCFs analyse the codec and media characteristics contained within the SDP request to determine if the characteristics are within those allowed for IMS sessions by the user&#39;s subscriber profile (for the requested service) in the IMS domain. Thus, a S-CSCF would be able to reject a session initiation attempt when the user&#39;s IMS subscription does not allow the use of a particular media type or codec (for a particular IMS Service). The P-CSCFs analyse the codec and media characteristics contained within the SDP request to determine if the characteristics are within those allowed for IMS sessions by the IMS Provider. Thus, a P-CSCF would be able to reject a session initiation attempt when the IMS Provider does not support a particular media type or codec. 
         [0010]      FIG. 2  depicts the worst case scenario where the P-CSCFs and S-CSCFs at each side of the communication path find media parameters that are not allowed. As shown each P-CSCF and S-CSCF rejects the session initiation attempt with a SIP 488 Reject response. Each SIP 488 message includes the media characteristics that would be acceptable to the rejecting P-CSCF or S-CSCF. Each time it receives the SIP 488 reject message, the UE uses this information to re-attempt the session initiation. 
         [0011]    As UEs become more advanced and increase their capabilities, they will support an increasing number of codecs and media characteristics. The UEs and clients will try to initiate services making use of the highest capabilities they support. As a result there will be an increasing tendency for message flows such as those shown in  FIG. 2  to take place. For example, IMS clients will normally initiate session establishment offering all the codecs they support (unless the user has manually configured each client application otherwise), ignoring any restriction of codec set by the IMS operator. 
         [0012]    One effect of the flows shown in  FIG. 2  is that it can lead to a long (probably unacceptable) session set-up time. In addition, the same situation will be experienced in subsequent sessions because the UE is only configured to modify a session request to take account the acceptable session information received with the 488 reject message on a per session basis (i.e. acceptable session characteristics information is not used for subsequent session initiation attempts). 
         [0013]    It is an object of the present invention to alleviate the aforementioned problems. 
       SUMMARY 
       [0014]    According to a first aspect of the present invention there is provided a method of enabling user equipment to establish a communication session over an IMS network. The communication session is enabled by one or more call/session control functions in the network in accordance with media characteristics that define the network resources to be utilised for the session. The method includes: receiving within the IMS network a subscriber registration request originating from the user equipment and, in response thereto, sending to the user equipment an identification of allowable media characteristics. 
         [0015]    The method may further comprise storing the identification of allowable media characteristics in a memory in the user equipment. 
         [0016]    In embodiments of the invention, the method further comprises sending a session initiation request from the user equipment to the network, wherein the session initiation request includes a specification of media characteristics for the session based on the allowable media characteristics. 
         [0017]    In embodiments of the invention, the registration request comprises a SIP REGISTER message. The identification of allowable media characteristics may be sent to the user equipment in a SIP 2000K message. 
         [0018]    It is an advantage that the UE is able to learn the allowable media characteristics when it registers and can then use these when it initiates a session. In this way, there will be a reduced number of Reject responses and the session can be established more quickly. 
         [0019]    In embodiments of the invention at least one of the call/session control functions is a P-CSCF and the allowable media characteristics include media characteristics based on Access Network policies applied by the P-CSCF. 
         [0020]    In embodiments of the invention at least one of the call/session control functions is a S-CSCF and the allowable media characteristics include media characteristics based on Home Network policies applied by the S-CSCF. 
         [0021]    The P-CSCF may receive a message from an S-CSCF that includes an indication of the allowable media characteristics based on Home Network policies applied by the S-CSCF and merges these with indications of the media characteristics based on Access Network policies before sending indications of merged allowable media characteristics to the user equipment. 
         [0022]    In embodiments of the invention, the method further comprises the step of sending updated allowable media characteristics to the UE in response to a re-registration message sent from the UE to the IMS network. It is an advantage that, when allowable characteristics change, the UE can be updated so that it is kept informed of the latest allowable characteristics. 
         [0023]    In embodiments of the invention, the identification of allowable media characteristics is inserted in a document into a message sent to the UE in response to the registration request. The document may be an XML document. 
         [0024]    According to a second aspect of the present invention there is provided a network node for performing a call/session control function in an IMS network. The control function includes implementation of allowable media characteristics that define network resources provided for communications sessions. The device includes: means for sending a message to user equipment in response to a registration request from the user equipment, wherein the message comprises information identifying the allowable media characteristics. 
         [0025]    The network node may comprise a P-CSCF having means for receiving a response message indicating allowable media characteristics based on Home Network policies from one or more other network nodes. The P-CSCF is configured to send the message to the UE including information identifying allowable media characteristics based on said Home Network policies and information identifying allowable media characteristics based on Access Network policies. 
         [0026]    The P-CSCF may be configured to merge the indications of allowable media characteristics based on Home Network policies and Access Network policies and to send the message to the UE including the merged indications. 
         [0027]    According to a third aspect of the present invention there is provided user equipment configured to participate in a communication session over an IMS network. The communication session is enabled by one or more call/session control functions in the network in accordance with media characteristics that define network resources to be utilised for the session. The UE includes: means for sending a registration request to register with the network; means for receiving a message in response to the registration request from the network, wherein the message comprises information identifying allowable media characteristics; and means for applying the allowable media characteristics to subsequent session requests. 
         [0028]    The information in the message may comprise a document that includes allowable media characteristics based on Access Network policies, and/or allowable media characteristics based on Home Network policies. 
         [0029]    The allowable media characteristics based on Access Network policies and the allowable media characteristics based on Home Network policies may be received in different policy documents, the user equipment comprising means for merging the Access Network and Home Network policies. 
         [0030]    The user equipment may further comprise means for storing said information identifying allowable media characteristics. 
         [0031]    The user equipment may further comprise means for generating a re-registration request and means for receiving information identifying updated allowable media characteristics in response to the re-registration request. 
         [0032]    In embodiments of the invention the message further comprises additional information relating to other types of network policies, the user equipment storing the additional information for use in generating subsequent requests. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0033]    Embodiments of the invention are described below with reference to the drawings, in which: 
           [0034]      FIG. 1  is a schematic illustration of a GPRS/PS access network showing how the IMS fits into the mobile network architecture. 
           [0035]      FIG. 2  is an illustration of the signal flows between a UE and network nodes where a call/session request is rejected under existing procedures. 
           [0036]      FIG. 3  is an illustration of the signal flows between a UE and network nodes for registration and session set up in accordance with an embodiment of the invention. 
           [0037]      FIG. 4  is an illustration of the signal flows between a UE and network nodes for re-registration and session set up in accordance with an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0038]    The problems introduced above are further illustrated by way of the following example. Considering only the originating side of the communication path, let us imagine that the P-CSCF holds a policy to run a MTSI (Multimedia Telephone Services for IMS) speech session using the AMR-NB (Adaptive Multi-Rate-Narrow Band) codec at a maximum of 5.9 kbps, and the S-CSCF holds a policy for that particular originating user to run MTSI speech sessions with AMR-NB codec at a maximum of 5 kbps. If the user owns an advanced terminal capable of running MTSI speech calls with multiple codecs including AMR-NB and the UE offers all the codecs supported at every MTSI session initiation attempt, then an MTSI speech call initiation attempt will be rejected:
       firstly by the P-CSCF which will indicate that MTSI speech calls using the AMR-NB codec will only be allowed at a maximum of 5.9 kbps, and   secondly by the S-CSCF which will indicate that for that user the AMR-NB codec is only supported at 5 kbps.       
 
         [0041]    When the user initiates a new MTSI speech call (again offering all the codecs it supports) this new call will again be rejected twice, as above. One possible solution (see change request CR to 3GPP CT 1 #45 C1-070034) would be for UEs to be allowed to cache policies received in 488 error responses. The mechanism proposed would provide means for the UE to progressively learn the network&#39;s policies from the service rejections received from the IMS network. This would be achieved by means of the introduction of additional information elements within the SIP 488 Reject response. The additional information would include an indication that the acceptable SDP provided comes from either the local P-CSCF or S-CSCF. There would also be an advanced UE that derives restrictions for the negotiation of IMS Session characteristics from the improved SIP 488 Reject messages. The advanced UE would use the derived restrictions for the negotiation of IMS sessions in future session initiation attempts until the UE is re-authenticated within the IMS system. 
         [0042]    However, the mechanism suggested above presents some drawbacks. Firstly, it could take two round trips of unsuccessful session initiation attempts for the UE to learn about local P-CSCF and S-CSCF restrictions in the negotiation of session characteristics. Secondly, in order for the UE to be able to update the policy restrictions, especially in the case when these need to be upgraded, it would only cache the information learnt in between re-authentications. This is configurable within IMS, but if executed too often it represents a sub-optimal procedure because the first drawback above will potentially be repeated at each re-authentication even if there are no changes in the restrictions to be updated. 
         [0043]    Embodiments of the invention use another approach. In general, the IMS network may have policies that affect the establishment of IMS sessions. These policies may be applied either by the user&#39;s home IMS network, or by the network that the user&#39;s UE is visiting (in the event that this is not the home network). As explained above, these policies are applied in the CSCF nodes through which the session is being established and may result in the session being rejected. The basic concept of this invention is to allow the UE to obtain such policies pertaining to its visited and home IMS networks at the time the UE registers with the IMS. This provides the UE with the ability to initiate a session establishment request with a high probability of being accepted by the visited and home IMS networks. These policies are sent to the UE as part of the normal registration and re-registration procedures, in a response to the SIP REGISTER message. 
         [0044]    Two alternative embodiments are: 
         [0045]    1) the policies of the P-CSCF and S-CSCF are merged into one policy in the network prior to being sent to the UE; and 
         [0046]    2) the policies of the P-CSCF and S-CSCF are sent to the UE as separate policies and are merged by the UE. 
         [0047]    Note that the policies may also take into account potential dynamic conditions in which the UE may find itself, e.g. depending on the type of access it is using. 
         [0048]    The mechanism for the UE to learn the network&#39;s policies at the time of registration with the IMS includes:
       Downloading to the UE of the policies affecting the establishment of IMS Sessions that are provisioned at the local P-CSCF and S-CSCF in the response to the initial SIP REGISTER procedure.   Downloading of updates of the policies for the establishment of IMS Sessions that are provisioned at the local P-CSCF and S-CSCF in the response to the subsequent SIP re-REGISTER procedure.   An advanced UE that uses the knowledge of the policies for the establishment of IMS sessions for all the session initiation attempts.       
 
         [0052]      FIG. 3  depicts the revised SIP REGISTER method of this invention. 
         [0053]    At step  301  the originating UE sends the SIP REGISTER request to the network in the normal manner. This is sent to the P-CSCF, which forwards it to the S-CSCF, from where the S-CSCF further contacts the HSS for user credentials and user profile information (step  302 ). Typically, authentication of the user will be required, which means that the S-CSCF must obtain the user credentials from the HSS before responding to the SIP REGISTER request with a 2000K message. This involves additional SIP round trips which are not shown here in  FIG. 3  for simplicity. 
         [0054]    Once interactions with the HSS are successfully completed, the S-CSCF on the originating side includes policy rules that dictate the characteristics that are allowed for IMS sessions by the user&#39;s subscriber profile in the IMS domain. In this case one of the policy rules relating to MTSI speech calls is a limitation of a maximum of 5 kbps for audio data. At step  303 , the local (originating side) S-CSCF inserts “Home Network” policies within the 2000K(REG) message. These include the policy rule limiting audio data to  5 kbps for MTSI speech calls. 
         [0055]    At step  304  the SIP 2000K message, with the additional information is forwarded to the P-CSCF. The P-CSCF on the originating side includes policy rules that dictate the characteristics that are allowed for IMS sessions by the IMS Provider. In this case, one of the policy rules restricts MTSI speech calls to use of audio with an AMR-NB codec. At step  305 , the local P-CSCF inserts “Access Network” policies within 2000K(REG). These include the policy rule limiting audio for MTSI speech calls to use of the AMR-NB codec. 
         [0056]    At step  306  the SIP 2000K message with all the policy rules added by the S-CSCFs and P-CSCFs is received by the UE. Thus, as part of the registration procedure, the UE knows the policies for the establishment of IMS Sessions set at the local P-CSCF and S-CSCF. 
         [0057]    At step  310 , the user wishes to initiate an MTSI speech session. At step  310 , because the UE knows the policy restrictions based on the information received with the SIP 2000K message on registering, the UE can generate a SIP INVITE message that includes the appropriate codec and media characteristics (in this case audio data at 5 kbps with the AMR-NB codec). As these characteristics are allowed, the INVITE request will be allowed and the responses  314  will not contain any 488 rejects. At step  316  the session set-up can continue. 
         [0058]      FIG. 4  illustrates the signal flows that enable the UE to be notified of updates of policies by means of the Re-REGISTER process. In this example, at step  400  the restriction of the maximum audio data of  5  kbps is upgraded to a maximum of 5.9 kbps. This policy change is implemented by the S-CSCF. At step  401 , the UE sends a re-REGISTER message to the network. Re-registering of UEs occurs at predetermined periodic intervals, and is used, amongst other things, as a means for the network to re-authenticate the user and make sure the UE is still active. 
         [0059]    When, at step  402 , the interactions with the HSS are completed, then, at step  403 , the S-CSCF inserts the changed policy rule into the SIP 2000K message, as before. This is returned, via the P-CSCF (where no changes to the policy rules implemented by the P-CSCF have occurred in this example). The P-CSCF then forwards the SIP 2000K message to the UE. 
         [0060]    At step  410 , when the user next wants to initiate a MTSI speech call, the UE, at step  411 , knowing the updated restrictions, generates the appropriate SIP INVITE message, which includes an increase in the audio data to 5.9 kbps. At step  412  the SIP INVITE is forwarded to the network taking account of the updated policy at the S-CSCF, and as before, no  488  reject messages are returned at step  414 . This means that the session set-up is allowed to continue at step  416 . 
         [0061]    The insertion of policies into the SIP 2000K message may be performed using a policy document, for example an XML document. In embodiment (1), where the policies are merged at the P-CSCF, the P-CSCF selects the applicable Access Network policy rules and merges these with the policy document coming from the S-CSCF (containing the Home Network policy rules), which is contained in the body of the 2000K message sent from the S-CSCF to the P-CSCF (step  304  in  FIG. 3 ). Merging the policies involves specifying only the most severe restrictions that apply. In the example of  FIG. 3 , this means that the merged policies would not need to include the restriction of a maximum of 5.9 kbps placed on use of the codec AMR-NB by the P-CSCF, because this is not as severe as the 5.0 kbps restriction placed by the S-CSCF. The merged policy document is then added to the body of the 2000K message (at step  305 ) by the P-CSCF and forwarded to the UE (step  306 ). The UE then stores the merged policies in its memory. 
         [0062]    In XML, schemas describe the type of a document, for example the constraints that are placed on the structure and contents of a document of that type. In the present case, the schema of the policy document may be the same as defined in draft-ietf-sipping-media-policy-dataset-04. This draft defines a document format for media characteristics of SIP sessions, the Media Policy Dataset Format (MPDF). The MPDF format is based on XML and extends the Schema for SIP User Agent Profile Data Sets by specifying a data set for media characteristics. This format can be used to describe the media characteristics of a given SIP session (e.g. the media types and codecs used) in a session info document based on the session description of a session. The MPDF format can also be used to express policies for SIP sessions in a session policy document. The two types of MPDF documents, session information and session policy documents, share the same set of XML elements to describe session characteristics. 
         [0063]    This method may also be used to convey other information to the UE (e.g. other types of policies for the UE). 
         [0064]    When the UE initiates a session, it does so by referring to the stored policies in its memory, and offers only session characteristics that comply with the policies. This means that there will be fewer  488  rejections (only those coming from the terminating side of the communication path) and session initiation can be established immediately using the optimum allowed characteristics. 
         [0065]    In embodiment 2) where un-merged policies are sent to the UE, a similar approach is used, but with the following differences. 
         [0066]    The S-CSCF inserts “Home Network” policies in a document (e.g. an XML document) within 2000K(REG) and includes an indication that it (the S-CSCF) is the source of the policy. The P-CSCF inserts “Access Network” policies in another document within 2000K(REG) and includes an indication that it (the P-CSCF) is the source of the policy. 
         [0067]    The UE receives the policies for the establishment of IMS sessions set at the local P-CSCF and S-CSCF as separate policies within the REGISTER procedure (2000K). Prior to initiating a session the UE merges the policies. 
         [0068]    The policy documents may be described by the same XML schemas as in embodiment (1)—i.e. draft-ietf-sipping-media-policy-dataset-04. 
         [0069]    This method may also be used to convey other information to the UE (e.g. other types of policies for the UE). 
         [0070]    In both embodiments (1) and (2), the UE is informed of updates of policies by means of the re-REGISTER process as described above in association with  FIG. 4 . In embodiment (1) the updated policies are sent to the UE in a document that is merged by the P-CSCF, whereas in embodiment (2) separate policy update documents are sent and these are merged by the UE.