WO2015149844A1

WO2015149844A1 - Charging authorisation at ims session modification

Info

Publication number: WO2015149844A1
Application number: PCT/EP2014/056482
Authority: WO
Inventors: Ove Karlsson
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-03-31
Filing date: 2014-03-31
Publication date: 2015-10-08

Abstract

A method in an IP Multimedia Subsystem, IMS, telecommunication network, wherein a plurality of user equipments, UEs, are connected to the IMS network. An IMS node implementing a charging trigger function, CTF receives, from a first UE, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request comprises details of a requested modification to the ongoing IMS session. The IMS node then sends a credit control request, CCR, to an online charging system, OCS, node in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification. The OCS node receives the CCR, and determines, using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed. The OCS node then sends a credit control answer, CCA, to the IMS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed. The IMS node receives the CCA and examines the authorisation response. If the authorisation response indicates that the requested modification is allowed, the IMS node sends the modification request or modification response to the second UE. If the authorisation response indicates that the requested modification is not allowed, the IMS node sends a further modification response to the first UE and optionally the second UE indicating that the requested modification is not allowed.

Description

Charging Authorisation at IMS Session Modification

Technical Field The invention relates to improvements in online charging authorisation in an IMS network. More particularly, the invention relates to handling modifications to ongoing sessions at a charging trigger function and an online charging service.

Background

In IP Multimedia Subsystem (IMS) networks, the Online Charging System (OCS) is the entity that performs real-time credit control. Its functionality includes transaction handling, rating, online correlation and management of subscriber accounts/balances. The OCS can also include functionality for controlling user usage of services, e.g. authorising the use of services according to conditions set by the user or the network. For example, a user may establish a restriction on their account which prevents data services from being accessed at certain times of day, or may set limits on their account to stop voice, data, or messaging once a certain charging value has been reached over a period (e.g. to limit the amount of money spent on prepaid phone plans).

The behaviour of the OCS is defined in the standards document 3GPP TS 32.299 v12.3.0 ("Diameter charging applications"), which in turn implements IETF RFC 4006 ("Diameter Credit Control") and the Diameter protocol. Figure 1 shows an authorisation request according to the current standard. The node labelled "IMS Node" can be any node which implements the Charging Trigger Function, CTF. The CTF is the function which sends requests to the OCS regarding sessions in the IMS. The CTF is generally implemented in a Call Session Control Function, CSCF, or Application Server, AS, involved in session handling, to ensure that all session establishment signalling passes through the CTF. According to the standard, the authorisation can occur at one of two points during session establishment (shown as A and B in Figure 1 ), either in response to an INVITE, or in response to a 200OK (INVITE) (or equivalent response to another session initiation request). Either of these can be defined as trigger points for the CTF, along with other factors (e.g. availability of online charging on the subscriber's account, type of service requested, etc.). When the trigger occurs at the CTF, the CTF sends a Credit Control Request, CCR, to the OCS. The CCR includes details about the new session, and requests a quota of charging units for the session (and/or other charging operations, such as reserving units or deducting already used units). The OCS decides whether to authorise the requested service based on the details provided by the CCR. The OCS then sends a Credit Control Answer, CCA, to the CTF. The CCA contains a result code, which indicates whether the request was successful, and, if applicable, a quota for the session (or other requested charging data).

The result code may indicate success, a transient failure, or a permanent failure. Some failure types (e.g. 401 1 : Credit control not applicable) will still allow the service to be established, but most will either prompt the CTF to resend the CCR (e.g. in the case of a failure in transmission of the CCR), or to terminate the session being established (e.g. if the requested session is not authorised by the OCS).

Each SIP session will be associated with a single charging session between a CTF and an OCS. Therefore, all requests for authorisation for session modification, or for new services which run within an ongoing SIP session must be made as part of the charging session for the ongoing SI P session. Examples of session modifications which would require re-authorisation with the OCS include adding video or file sharing services to a voice call.

Figure 2 shows a request for authorisation of session modification according to the current standards. As before, either A or B can be defined as trigger points for the CTF. The modification request may be a SIP Re-INVITE or UPDATE, and the modification response may be a 200 OK (Re-INVITE) or 200 OK (UPDATE). When the trigger occurs at the CTF, the CTF sends a CCR containing details of the modification to the existing session, and requests a quota of charging units for the session (and/or other charging operations). The OCS decides whether or not to authorise the requested service, and then sends a CCA to the CTF. The CCA contains a result code, which indicates whether the request was successful, and, if applicable, a quota for the modified session (or other requested charging data). Summary With the present standards, if a subscriber makes a request for modification of an ongoing session (e.g. adding video to a voice call), and the authorisation for this request is denied by the OCS, the OCS will return a CCA with a result-code indicating failure. The CTF will, having received a CCA with a result-code indicating failure, proceed to not only prevent the modification to the session, but also terminate the ongoing session. The signalling in this situation is show in Figure 3. This occurs as there is no way in the currently defined standard for the CTF to distinguish between the case where authorisation is denied for only the modification to the service, and the case where authorisation is denied for both the modification and continuation of the ongoing service.

The alternative approach (of not dropping the connection when the result code indicates failure of an authorisation request for a modified session) is undesirable for a network, as it can allow users to continue sessions when they have exceeded their allowed service usage, or can result in mismatched states between the CTF and the OCS.

This behaviour results in an undesirable experience for the end user (e.g. having a voice call dropped completely when attempting to add video calling), and there is a need to provide a solution which allows the modification to be rejected without affecting the ongoing session.

According to a first aspect of the invention, there is provided a method in an IP Multimedia Subsystem, IMS, telecommunication network, wherein a plurality of user equipments, UEs, are connected to the IMS network. An IMS node implementing a charging trigger function, CTF receives, from a first UE, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request comprises details of a requested modification to the ongoing IMS session. The IMS node then sends a credit control request, CCR, to an online charging system, OCS, node in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification. The OCS node receives the CCR, and determines, using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed. The OCS node then sends a credit control answer, CCA, to the IMS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed. The IMS node receives the CCA and examines the authorisation response. If the authorisation response indicates that the requested modification is allowed, the IMS node sends the modification request or modification response to the second UE. If the authorisation response indicates that the requested modification is not allowed, the IMS node sends a further modification response to the first UE and optionally the second UE indicating that the requested modification is not allowed.

According to a second aspect, there is provided a method in a node of an IP multimedia system, IMS, telecommunications network, wherein the node implements a charging trigger function, CTF, and a plurality of user equipments, UEs, are connected to the IMS network. The IMS node receives, from a first UE, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request comprising details of a requested modification to the ongoing IMS session. The IMS node then sends a credit control request, CCR, to an online charging system, OCS, node in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification. The IMS node then receives a credit control answer, CCA, from the OCS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed. The IMS node examines the authorisation response. If the authorisation response indicates that the requested modification is allowed, the IMS node sends the modification request or modification response to the second UE. If the authorisation response indicates that the requested modification is not allowed, the IMS node sends a further modification response to the first UE and optionally the second UE indicating that the requested modification is not allowed.

According to a third aspect, there is provided a method in an online charging system, OCS node of an IP multimedia system, IMS, telecommunications network, wherein a plurality of user equipments, UEs, are connected to the IMS network. The OCS node receives a credit control request, CCR, from an IMS node implementing a charging trigger function, CTF, in respect of a charging session associated with an ongoing IMS session between a first UE and a second UE wherein the CCR identifies the charging session and contains an indication that the CCR is an authorisation request for the requested modification and contains the details about a requested modification to the ongoing IMS session. The OCS node determines, using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed. The OCS node sends a credit control answer, CCA, to the IMS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed.

According to a fourth aspect, there is provided an apparatus configured to operate as a node of an IP multimedia system, IMS, telecommunications network, the apparatus comprises a first transceiver, a second transceiver, and a processor. The first transceiver is configured to communicate with other entities of the IMS network. The second transceiver is configured to communicate with an online charging system, OCS, node. The processor is configured to implement a charging trigger function, CTF, and further configured to:

· receive, from a first UE via the first transceiver, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request or modification response comprising details of a requested modification to the ongoing IMS session;

• send a credit control request, CCR, to the OCS node via the second transceiver in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification;

• receive a credit control answer, CCA, from the OCS node via the second transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed;

• examine the authorisation response;

• if the authorisation response indicates that the requested modification is allowed: o send the modification request or modification response to the second UE via the first transceiver;

• if the authorisation response indicates that the requested modification is not allowed:

o send a further modification response to the first UE via the first transceiver, the modification response indicating that the requested modification is not allowed.

According to a fifth aspect there is provided an apparatus configured to operate as an online charging system, OCS, node of an IP multimedia subsystem, IMS, telecommunications network. The apparatus comprises a transceiver and a processor. The transceiver is configured to communicate with an IMS node implementing a charging trigger function, CTF.

The processor is configured to:

· receive a credit control request, CCR, from the IMS node via the transceiver, in respect of a charging session associated with the ongoing IMS session wherein the CCR identifies the charging session and contains an indication that the CCR is an authorisation request for the requested modification and details about a requested modification to an ongoing IMS session between a first UE and a second UE;

• determine, using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed; and

• send a credit control answer, CCA, to the IMS node via the transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed.

According to a sixth aspect there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to the above aspects. The computer program may be carried on a carrier such as an electronic signal, optical signal, radio signal, or a computer readable storage medium. It is an advantage that requests for modifications of an existing session may be disallowed by the online charging system without risking interruption of the original session. Brief Description of the Drawings

Figure 1 is a signalling diagram of an online charging procedure in an IMS network; Figure 2 is a further signalling diagram of an online charging procedure in an IMS network;

Figure 3 is a further signalling diagram of an online charging procedure in an IMS network;

Figure 4 is a schematic diagram of an IMS network;

Figure 5 is a flowchart showing a method for an online charging procedure in an IMS network;

Figure 6 is a signalling diagram of a modified online charging procedure in an IMS network;

Figure 7 is a modified signalling diagram of a modified online charging procedure in an IMS network;

Figure 8 is a modified signalling diagram of a modified online charging procedure in an IMS network;

Figure 9 is a modified signalling diagram of a modified online charging procedure in an IMS network;

Figure 10 is a modified signalling diagram of a modified online charging procedure in an IMS network.

Detailed Description

As noted above, if a request for modification of an ongoing session is not authorised, this will result in the termination of the ongoing session. Improvements to the currently defined online charging procedure are described below to overcome this problem. The new elements of the CCR and CCA described herein may be implemented as additional Attribute/Value Pairs (AVPs) to those described in the current standards, or as replacement for wildcard or blank AVPs in current standards, which will cause them to be ignored by legacy equipment and prevent compatibility problems (other than the legacy equipment still experiencing the problem described above). The methods disclosed below will be described with reference to the network shown in Figure 4. UEs 101 and 102 are connected to an IMS network 200. Each UE may be connected to a separate network (e.g. to a different carrier), but the precise details of the network are not important. Within the IMS network 200 is an IMS node implementing a CTF 300, which is connected to an OCS node 400 over the Ro interface. The IMS node 300 may be an AS or a CSCF. The internal structure of the IMS node implementing the CTF 300 and the OCS node 400 will be described later. Figure 5 shows a flowchart of a modified online charging method, and Figure 6 shows a signalling diagram for the method. Figure 6 shows the case where the CTF is triggered by the UE 101 sending a modification request (i.e. the equivalent to case A in Figure 2). The CTF may also be triggered by the UE 101 sending a modification response in response to a modification request sent by the UE 102 (i.e. the equivalent to case B in Figure 2). The IMS node 300 (or other node implementing the CTF) receives, from the first UE 101 , a modification request or response (case A or case B in Figure 6) relating to an ongoing IMS session between the first UE 101 and the second UE 102 (S101 ). The IMS node 300 then sends a CCR to the OCS node 400 in respect of the charging session associated with the ongoing session (S102). The CCR identifies the charging session, and contains the details about the requested modification to the ongoing IMS session, and an indication that the CCR is an authorisation request for the requested modification (Auth request). The OCS node 400 receives the CCR (S103) and determines whether or not the requested modification is allowed based on the details of the requested modification (S104). The OCS node 400 then sends a CCA to the IMS node 300 (S105). The CCA contains a result code which indicates that the request was handled successfully (Result-code), and an authorisation response which indicates whether or not the requested modification is allowed (Auth response). The IMS node 300 receives the CCA (S106) and examines the authorisation response (S107). If the requested modification is allowed, the IMS node 300 sends the modification request or response to the second UE 102 (S108). If the requested modification is not allowed, in the case where the CCR is sent in response to a modification request (A), the IMS node 300 sends a modification response to the first UE 101 indicating that the modification is not allowed. The signalling diagram for this scenario is shown in Figure 7. In the case where the CCR is send in response to a modification response (B), the IMS node 300 sends a further modification response to the first UE 101 and the second UE 102.

If the OCS node 400 determines that the ongoing session should be terminated (e.g. since a subscriber has run out of credit completely on their account), then the result code in the CCA indicates that the request failed (giving the appropriate code as defined in the standards), and the IMS node 300 sends a modification response to the first UE 101 indicating that the session must be terminated. The signalling diagram for this scenario is shown in Figure 8.

The above method allows for the ongoing session not to be terminated if the modification is not allowed but the ongoing session is still allowed to proceed, whilst still keeping the intended functionality of the OCS in other cases. In order to ensure compatibility of the above method with current systems, the CCA and CCR can be implemented as Diameter messages over the Ro interface, as defined in the standards mentioned above. The new elements of the CCA and CCR can then be implemented as AVPs, e.g. using an AVP which is blank or wildcarded in the current standards. Since blank or wildcarded AVPs are ignored by devices implementing only the current standards, the functioning of these devices will not be affected if they receive a CCA or CCR with the AVP containing an Auth request/response relating to a requested modification.

The modification request may be a SIP Re-INVITE or UPDATE. As an example, the ongoing session may be a voice call, and the requested modification may be the addition of video or filesharing services to the voice call.

The above method may be further enhanced to include additional charging functionality. In current OCS systems, the CTF will periodically request a new quota for an ongoing session. This request may be combined with the method disclosed above as shown in Figure 9. When the IMS node 300 implementing the CTF receives the modification request or response, the IMS node 300 determines whether a trigger to request a new quota for the ongoing session is satisfied. If the trigger is not satisfied, the method proceeds as described previously. If the trigger is satisfied, then the CCR additionally contains a request for a new quota for the ongoing service. The OCS calculates the new quota for the ongoing service according to the relevant standards, and includes the new quota in the CCA. Note that since this quota is for the ongoing service, it will be included in the CCA whether or not the requested modification is permitted.

Generally, the modification request will specify a type of service, and provide several implementation options, e.g. the modification request may be for a video call, and provide several possible codecs. The modification response will indicate which of the implementation options has been selected by the UE 102. Therefore, as shown in Figure 10, the IMS node 300 implementing the CTF may request a quota for the modified service in a CCR sent after receipt of the modification response. This quota request comprises details of the modification to be made to the ongoing service, and may also comprise details of the ongoing service. The OCS then calculates a quota for the modified service, and may deduct used service units for the ongoing service and/or calculate a separate quota for the ongoing service, and includes the quota(s) in the CCA.

Referring back to Figure 4, schematic diagrams of the internal structure of the IMS node implementing the CTF and the OCS node are shown.

The IMS node implementing the CTF 300 comprises a first transceiver 301 , a second transceiver 302, and a processor 303. The first transceiver 301 is configured to communicate with other entities of the IMS network. The second transceiver 302 is configured to communicate with an OCS node. The processor 303 is configured to implement the CTF and further configured to receive, from the first UE via the first transceiver, a modification request or modification response relating to an ongoing IMS session between the first UE and the second UE. The processor is further configured to send a CCR to the OCS node via the second transceiver in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification. The processor is further configured to receive a credit control answer, CCA, from the OCS node via the second transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed. The processor is further configured to examine the authorisation response and, if the authorisation response indicates that the requested modification is allowed, to send the modification request or modification response to the second UE via the first transceiver; and if the authorisation response indicates that the requested modification is not allowed, to send a further modification response to the first UE via the first transceiver, the modification response indicating that the requested modification is not allowed.

The OCS node 400 comprises a transceiver 401 and a processor 402. The transceiver is configured to communicate with an IMS node implementing a CTF. The processor is configured to receive a CCR from the IMS node via the transceiver, in respect of a charging session associated with the ongoing IMS session wherein the CCR identifies the charging session and contains an indication that the CCR is an authorisation request for the requested modification and details about a requested modification to an ongoing IMS session between a first UE and a second UE; determine, using the details about the requested modification, whether or not the requested modification is allowed; and send a CCA to the IMS node via the transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed.

The methods above may be implemented by providing a computer program which, when executed on at least one processor, causes the processor to carry out the method. The computer program may be embodied on a carrier such as an electronic signal, an optical signal, a radio signal, or a non-transitory computer readable storage medium.

Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.

Claims

CLAIMS:

1 . A method in an I P Multimedia Subsystem, IMS, network, wherein a plurality of user equipments, UEs, are connected to the IMS network, the method comprising: at an IMS node implementing a charging trigger function, CTF, performing the steps of:

receiving (S101 ), from a first UE, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request comprising details of a requested modification to the ongoing IMS session;

sending (S102) a credit control request, CCR, to an online charging system, OCS, node in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification;

at the OCS node, performing the steps of:

receiving (S103) the CCR;

determining (S104), using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed;

sending (S105) a credit control answer, CCA, to the IMS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed;

at the IMS node, performing the steps of;

receiving (S106) the CCA;

examining (S107) the authorisation response;

if the authorisation response indicates that the requested modification is allowed:

sending (S108) the modification request or modification response to the second UE;

if the authorisation response indicates that the requested modification is not allowed: sending (S109) a further modification response to the first UE indicating that the requested modification is not allowed.

2. A method according to claim 1 , wherein the IMS node and the OCS node communicate over an Ro interface and the CCA and CCR are DIAMETER messages.

3. A method according to claim 1 or 2, wherein the indication that the CCR is an authorisation request for the requested modification and the authorisation response are attribute/value pairs, AVPs.

4. A method according to any of claims 1 to 3, and comprising, at the IMS node, if the authorisation response indicates that the requested modification is not allowed, sending the further modification response to the second UE.

5. A method according to any of claims 1 to 4, wherein the ongoing session is a voice call.

6. A method according to any of claims 1 to 5, and comprising:

at the IMS node, prior to sending the CCR, performing the steps of:

determining the status of the ongoing IMS session;

based on results of said determination, deciding whether or not to request a new quota for the ongoing IMS session ;

wherein, if the IMS node decides to request a new quota for the ongoing IMS session, the CCR contains a new quota request for the ongoing IMS session, and the method further comprises:

at the OCS node, prior to sending the CCA, performing the steps of:

determining a new quota for the ongoing IMS session;

wherein the CCA contains the new quota for the ongoing IMS session.

7. A method according to any of claims 1 to 5, wherein, the CCR contains a quota request for the modified IMS session, and the method further comprises:

at the OCS node, prior to sending the CCA, performing the steps of:

determining a quota for the modified IMS session;

wherein the CCA contains the quota for the modified IMS session.

8. A method in a node of an IP multimedia system, IMS, network, wherein the node implements a charging trigger function, CTF, and wherein a plurality of user equipments, UEs, are connected to the IMS network, the method comprising:

receiving (S106) a credit control answer, CCA, from the OCS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed;

examining (S107) the authorisation response;

if the authorisation response indicates that the requested modification is not allowed:

sending (S109) a further modification response to the first UE indicating that the requested modification is not allowed.

9. A method according to claim 8, wherein the IMS node and the OCS node communicate over an Ro interface and the CCA and CCR are DIAMETER messages.

10. A method according to claim 9, wherein the indication that the CCR is an authorisation request for the requested modification and the authorisation response are attribute/value pairs, AVPs.

1 1 . A method according to any of claims 8 to 10, and comprising, if the authorisation response indicates that the requested modification is not allowed, sending the further modification response to the second UE.

12. A method according to any of claims 8 to 1 1 , wherein the ongoing session is a voice call.

13. A method according to any of claims 8 to 12, and comprising, prior to sending the CCR:

determining a status of the ongoing IMS session;

based on results of said determination, deciding whether or not to request a new quota for the ongoing IMS session;

wherein, if the IMS node decides to request a new quota for the ongoing IMS session, the CCR contains a new quota request for the ongoing IMS session and the CCA contains a new quota for the ongoing IMS session.

14. A method according to any of claims 8 to 12, wherein the CCR contains a quota request for the modified IMS session, and the CCA contains the quota for the modified IMS session.

15. A method in an online charging system, OCS node of an IP multimedia system, IMS, network, wherein a plurality of user equipments, UEs, are connected to the IMS network, the method comprising:

receiving (S103) a credit control request, CCR, from an IMS node implementing a charging trigger function, CTF, in respect of a charging session associated with an ongoing IMS session between a first UE and a second UE wherein the CCR identifies the charging session and contains an indication that the CCR is an authorisation request for the requested modification and contains the details about a requested modification to the ongoing IMS session;

determining (S104), using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed; sending (S105) a credit control answer, CCA, to the IMS node, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed.

16. A method according to claim 15, wherein the IMS node and the OCS node communicate over an Ro interface and the CCA and CCR are DIAMETER messages.

17. A method according to claim 16, wherein the indication that the CCR is an authorisation request for the requested modification and the authorisation response are attribute/value pairs, AVPs.

18. A method according to any of claims 15 to 17, wherein the ongoing session is a voice call.

19. A method according to any of claims 15 to 18, wherein the CCR contains a new quota request for the ongoing IMS session, and comprising, prior to sending the CCA, determining a new quota for the ongoing IMS session, wherein the CCA contains the new quota for the ongoing IMS session.

20. A method according to any of claims 15 to 18, wherein, the CCR contains a quota request for the modified IMS session, and the method further comprises:

prior to sending the CCA:

determining a quota for the modified IMS session;

wherein the CCA contains the quota for the modified IMS session.

21 . An apparatus (300) configured to operate as a node of an IP multimedia system, IMS, telecommunications network, the apparatus comprising:

a first transceiver (301 ) configured to communicate with other entities of the

IMS network;

a second transceiver (302) configured to communicate with an online charging system, OCS, node;

a processor (303) configured to implement a charging trigger function, CTF, and further configured to:

receive, from a first UE via the first transceiver, a modification request or modification response relating to an ongoing IMS session between the first UE and a second UE, the modification request or modification response comprising details of a requested modification to the ongoing IMS session; send a credit control request, CCR, to the OCS node via the second transceiver in respect of a charging session associated with the ongoing IMS session, wherein the CCR identifies the charging session and contains the details about the requested modification to the ongoing IMS session and an indication that the CCR is an authorisation request for the requested modification;

receive a credit control answer, CCA, from the OCS node via the second transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed;

examine the authorisation response;

send the modification request or modification response to the second UE via the first transceiver;

send a further modification response to the first UE via the first transceiver, the modification response indicating that the requested modification is not allowed.

22. An apparatus according to claim 21 , wherein the second transceiver is configured to communicate with the OCS node over an Ro interface, and the CCA and CCR are DIAMETER messages.

23. An apparatus according to claim 22, wherein the indication that the CCR is an authorisation request for the requested modification and the authorisation response are attribute/value pairs, AVPs.

24. An apparatus according to any of claims 21 to 23, wherein the processor is further configured to, if the response indicates that the requested modification is not allowed, send the further modification response to the second UE.

25. An apparatus according to any of claims 21 to 24, wherein the processor is further configured to, prior to sending the CCR:

determine a status of the ongoing IMS session;

based on results of said determination, decide whether or not to request a new quota for the ongoing IMS session;

wherein the processor is further configures such that, if the result of said decision is to request a new quota, the CCR contains a new quota request for the ongoing IMS session and the CCA contains a new quota for the ongoing IMS session.

26. An apparatus 400 configured to operate as an online charging system, OCS, node of an IP multimedia subsystem, IMS, telecommunications network, the apparatus comprising:

a transceiver 401 configured to communicate with an IMS node implementing a charging trigger function, CTF;

a processor 402 configured to:

receive a credit control request, CCR, from the IMS node via the transceiver, in respect of a charging session associated with the ongoing IMS session wherein the CCR identifies the charging session and contains an indication that the CCR is an authorisation request for the requested modification and details about a requested modification to an ongoing IMS session between a first UE and a second UE;

determine, using the details about the requested modification to the ongoing IMS session, whether or not the requested modification is allowed;

send a credit control answer, CCA, to the IMS node via the transceiver, the CCA containing a result code which indicates that the request was handled successfully, and an authorisation response which indicates whether or not the requested modification is allowed.

27. An apparatus according to claim 26, wherein the transceiver is configured to communicate with the IMS node over an Ro interface and the CCR and CCA are DIAMETER messages.

28. An apparatus according to claim 27, wherein the indication that the CCR is an authorisation request for the requested modification and the authorisation response are attribute/value pairs, AVPs.

29. An apparatus according to any of claims 26 to 28, wherein the CCR contains a new quota request for the ongoing IMS session and the CCA contains a new quota for the ongoing IMS session, and the processor is additionally configured to, prior to sending the CCA, determine the new quota for the ongoing IMS session.

30. An apparatus according to any of claims 26 to 29, wherein the processor is additionally configured to determine a quota for the modified IMS session prior to sending the CCA, and wherein the CCR contains a quota request for the modified IMS session and the CCA contains the quota for the modified IMS session.

31 . A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 20.

32. A carrier containing the computer program of claim 31 , wherein the carrier is one of an electronic signal, optical signal, radio signal, or a computer readable storage medium