5.2.2.0 Introduction

32.2603GPPCharging managementIP Multimedia Subsystem (IMS) chargingRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The flows described in the present document specify the charging communications between IMS entities and the charging functions for different charging scenarios. The SIP messages and Charging Data transactions associated with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and they depend on the Charging Data Requests triggers configured by the operator.

5.2.2.1 Message flows – successful cases and scenarios

5.2.2.1.1 Session establishment – mobile origination

Figure 5.2.2.1.1.1 to figure 5.2.2.1.1.3 show the Charging Data transactions that are required between CSCF and CDF during session establishment originated by a UE.

Figures 5.2.2.1.1.1-5.2.2.1.1.3 below are illustrated in LBO roaming model where P-CSCF and CDF are located in VPLMN. The same figures are applicable for deployment of voice over IMS with home routed traffic, where P-CSCF is located in HPLMN, with the exception that the HPLMN CDF is used.

Scenario 1: Successful session establishment

Figure 5.2.2.1.1.1: Message sequence chart for session establishment (mobile origination)

1. The session is initiated.

2. The destination party answers and a final response are received.

3. Upon reception of the final response, the S-CSCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the S-CSCF CDR.

4. The CDF acknowledges the reception of the data and opens an S-CSCF CDR.

5. Same as 3, but for P-CSCF.

6. Same as 4, but creating a P-CSCF CDR.

Scenario 2: Successful session establishment with late SDP answer (SIP 200 OK triggering Charging Data Request)

Figure 5.2.2.1.1.2 shows the Charging Data transactions that are required between CSCF and CDF during session establishment originated by a UE.

Figure 5.2.2.1.1.2: Message sequence chart for session establishment
(SIP 200 OK triggering Charging Data Request) – mobile origination

1. The session is initiated.

2. The destination party answers and a response are received.

3. Upon reception of the SIP 200 OK, the S-CSCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the S-CSCF CDR.

4. The CDF acknowledges the reception of the data and opens an S-CSCF CDR.

5. Same as 3, but for P-CSCF.

6. Same as 4, but creating a P-CSCF CDR.

7. – 11. These steps are identical to steps 3. -7. of scenario 2 described in clause 5.2.2.1.3.

Scenario 3: Successful session establishment with late SDP answer (SIP ACK triggering Charging Data Request)

Figure 5.2.2.1.1.3 shows the Charging Data transactions that are required between CSCF and CDF during session establishment originated by a UE.

Figure 5.2.2.1.1.3: Message sequence chart for session establishment
(SIP ACK triggering Charging Data Request) – mobile origination

1. The session is initiated.

2. The destination party answers and a final response are received. If the final response includes a SDP offer only, then the CSCF shall wait for the SIP ACK.

3. The SIP ACK including the SDP answer is received.

4. Upon reception of the SIP ACK, the P-CSCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the P-CSCF CDR.

5. The CDF acknowledges the reception of the data and opens an P-CSCF CDR.

6. Same as 4, but for S-CSCF.

7. Same as 5, but creating a S-CSCF CDR.

5.2.2.1.2 Session establishment – mobile termination

Figure 5.2.2.1.2.1 shows the Charging Data transactions that are required between CSCF and CDF during a session establishment that is terminated to a mobile. The I-CSCF is only involved in the SIP INVITE transaction.

Figure 5.2.2.1.2.1 below is illustrated in LBO roaming model where P-CSCF and CDF are located in VPLMN. The same figure is applicable for deployment of voice over IMS with home routed traffic, where P-CSCF is located in HPLMN, with the exception that the HPLMN CDF is used.

Figure 5.2.2.1.2.1: Message sequence chart for session establishment (mobile termination)

1. The session is initiated.

2. The destination party answers and a final response are sent.

3. – 6. These steps are identical to the corresponding steps described in clause 5.2.2.1.1.

7. Upon reception of the SIP 200 OK, the I-CSCF sends an Charging Data Request[Event].

8. The CDF acknowledges the data received and creates an I-CSCF CDR.

5.2.2.1.3 Mid-session procedures

Figure 5.2.2.1.3.1 shows the Charging Data transactions that are required between CSCF and CDF when a UE generates a SIP (rE‑)iNVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed.

Figures 5.2.2.1.3.1-5.2.2.1.3.2 below are illustrated in LBO roaming model where P-CSCF and CDF are located in VPLMN. The same figures are applicable for deployment of voice over IMS with home routed traffic, where P-CSCF is located in HPLMN, with the exception that the HPLMN CDF is used.

Scenario 1: Mid-session procedures

Figure 5.2.2.1.3.1: Message sequence chart for media modification

1. Modified media information is received from the subscriber.

2. The destination party acknowledges the media modification.

3. At modification of a media, the S-CSCF sends Charging Data Request[Interim] to record modification of a media component in the S-CSCF CDR.

4. The CDF acknowledges the reception of the data and updates the S-CSCF CDR.

5. Same as 3, but for P-CSCF.

6. Same as 4, updating the P-CSCF CDR.

Scenario 2 : Mid-session procedures with late SDP answer (SIP ACK triggering Charging Data Request)

Figure 5.2.2.1.3.2 shows the Charging Data transactions that are required between CSCF and CDF when a UE generates a SIP (rE‑)iNVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed.

Figure 5.2.2.1.3.2: Message sequence chart for media modification (SIP ACK triggering Charging Data Request)

1. The UE generates a SIP RE‑INVITE or SIP UPDATE in mid-session.

2. The destination party replies with a response including a SDP offer. If the final response includes a SDP offer only, then the CSCF shall wait for the SIP ACK.

3. The SIP ACK including the SDP answer is received.

4. At modification of a media, the P-CSCF sends Charging Data Request[Interim] to record modification of a media component in the P-CSCF CDR.

5. The CDF acknowledges the reception of the data and updates the P-CSCF CDR.

6. Same as 4, but for S-CSCF.

7. Same as 5, updating the S-CSCF CDR.

5.2.2.1.4 Session release – mobile initiated

Figures 5.2.2.1.4.1 to 5.2.2.1.4.2 show the Charging Data transactions that are required between CSCF and CDF for a session release that is initiated by the UE.

Figures 5.2.2.1.4.1-5.2.2.1.4.2 below are illustrated in LBO roaming model where P-CSCF and CDF are located in VPLMN. The same figures are applicable for deployment of voice over IMS with home routed traffic, where P-CSCF is located in HPLMN, with the exception that the HPLMN CDF is used.

Scenario 1: Successful session release (SIP BYE triggering Charging Data Request)

Figure 5.2.2.1.4.1: Message sequence chart for session release (SIP BYE triggering Charging Data Request)

1. The session is released.

2. At session termination the P-CSCF sends Charging Data Request[Stop] to record stop of a session and stop of a media component in the
P-CSCF CDR.

3. The CDF acknowledges the reception of the data and closes the P-CSCF CDR.

4. Same as 2, but for S-CSCF.

5. Same as 3, closing the S-CSCF CDR.

6. The release is acknowledged.

Scenario 2: Successful session release (SIP 200 OK triggering Charging Data Request)

Figure 5.2.2.1.4.2: Message sequence chart for session release (SIP 200 OK triggering Charging Data Request)

1. The session is released.

2. The release is acknowledged.

3. At acknowledgement of SIP session termination and, if required, Rx session termination, the P-CSCF sends Charging Data Request[Stop] to record stop of a session and stop of a media component and information from the acknowledgement message (e.g. user location retrieved as per Annex A.10.5 of TS 29.214[214] ) in the P-CSCF CDR. Reported charging information must rely on the time when SIP BYE message is received and not when the corresponding acknowledgement is received.

4. The CDF acknowledges the reception of the data and closes the P-CSCF CDR.

5. Same as 3, but for S-CSCF.

6. Same as 4, closing the S-CSCF CDR.

5.2.2.1.5 Session-unrelated procedures

Figure 5.2.2.1.5.1 shows the Charging Data transactions that are required between CSCF and CDF for session-unrelated IMS procedures, i.e. those that relate to the Charging Data Request [event], as listed in table 5.2.1.1.

Figure 5.2.2.1.5.1 below is illustrated in LBO roaming model where P-CSCF and CDF are located in VPLMN. The same figure is applicable for deployment of voice over IMS with home routed traffic, where P-CSCF is located in HPLMN, with the exception that the HPLMN CDF is used.

Figure 5.2.2.1.5.1: Message sequence chart for session-unrelated procedure

1. The P-CSCF receives a "SIP request" (e.g. SUBSCRIBE) from the subscriber.

2. The "SIP Request" is acknowledged by the "SIP response" as follows:

– in the successful case, a SIP 200 OK message is returned;

– in case of failure an appropriate SIP error message is returned.

Depending on the used SIP method, there might be additional signalling between steps 1 and 2.

3. After the completion of the procedure, the S-CSCF sends Charging Data Request[Event] to record transaction specific information in the S-CSCF CDR.

4. The CDF acknowledges the reception of the data and produces an S-CSCF CDR.

5. Same as 3, but for P-CSCF.

6. Same as 4, creating a P-CSCF CDR.

5.2.2.1.6 Session establishment – PSTN initiated

Figure 5.2.2.1.6.1 shows the Charging Data transactions that are required between MGCF and CDF during session establishment initiated from the PSTN side.

Figure 5.2.2.1.6.1: Message sequence chart for session establishment (PSTN initiated)

1. The session is originated from the PSTN.

2. The session setup is triggered in the IMS.

3. The destination party answers and a final response are received.

4. MGCF forwards an answer message to the PSTN.

5. Upon reception of the final response, the MGCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the MGCF CDR.

6. The CDF acknowledges the reception of the data and opens a MGCF CDR.

5.2.2.1.7 Session establishment – IMS initiated

Figure 5.2.2.1.7.1 shows the Charging Data transactions that are required between BGCF, MGCF and CDF during session establishment initiated from the IMS side.

Figure 5.2.2.1.7.1: Message sequence chart for session establishment (IMS initiated)

1. The session is originated from the IMS.

2. A session towards PSTN is established.

3. The destination party answers and an answer message are received.

4. A final response message is sent to the session originator.

5. Upon reception of the answer message, the MGCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the MGCF CDR.

6. The CDF acknowledges the reception of the data and opens a MGCF CDR.

7. Upon reception of the SIP 200 OK message, the BGCF sends an Charging Data Request[Event] to create a BGCF CDR.

8. The CDF acknowledges the reception of the data and creates a BGCF CDR.

5.2.2.1.8 Session release – PSTN initiated

Figure 5.2.2.1.8.1 shows the Charging Data transactions that are required between MGCF and CDF during a PSTN initiated session release.

Figure 5.2.2.1.8.1: Message sequence chart for session release (PSTN initiated)

1. The session release is initiated from PSTN.

2. Session release continues within IMS.

3. The reception of the release message is acknowledged.

4. Upon reception of the release message, the MGCF sends an Charging Data Request[Stop] to record stop of a session in the MGCF CDR.

5. The CDF acknowledges the reception of the data and closes the MGCF CDR.

5.2.2.1.9 Session release – IMS initiated

Figure 5.2.2.1.9.1 shows the Charging Data transactions that are required between MGCF and CDF during an IMS initiated session release.

Figure 5.2.2.1.9.1: Message sequence chart for session release (IMS initiated)

1. The session release is initiated from the IMS side.

2. A release message is sent towards PSTN.

3. The acknowledgement of the release message is received from PSTN.

4. Upon reception of the SIP BYE message the MGCF sends an Charging Data Request[Stop] to record stop of a session in the MGCF CDR.

5. The CDF acknowledges the reception of the data and closes the MGCF CDR.

5.2.2.1.10 Multi-Party call

Figure 5.2.2.1.10.1 shows the establishment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) performs third party call control with the MRFC, where the S-CSCF is in the signalling path. The AS that is in control of the ad hoc conference is aware of the MRFC capabilities. Note that only accounting information sent from the MRFC is shown in detail in figure 5.2.2.1.10.1. The SIP messages are for illustrative purpose only.

Figure 5.2.2.1.10.1: Message sequence chart for Multi-party call establishment in MRFC

1. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from UE-1for putting all parties together to a multi-party call.

2. – 3. Request and acknowledgement to initiate multi-party call. MRFC assigns a conference-ID that is used by the AS in subsequent interactions with the MRFC in SIP INVITE messages connecting other endpoints (see TS 23.228 [201]). Path establishment between AS and MRFC for UE-2.

4. At start of session establishment the MRFC sends an Charging Data Request[ Start] to record start of multi-party call in the MRFC CDR

5. The CDF acknowledges the reception of the data and creates the MRFC CDR. ‘Calling Party Address’, ‘Service Request Time Stamp’, ‘Service ID’ (holding the conference-ID) etc. are included in the MRFC CDR

6 – 7. Path establishment between UE-2 and AS. Same ICID is used as for the path between AS and MRFC for UE-2 (step 2. – 3.).

8 Acknowledgement of path between AS and MRFC for UE-2.

9. The MRFC may send an Charging Data Request[Interim] to report that UE-2 has been connected to the multi-party call.

10. The CDF acknowledges the reception of the data and includes UE-2 in the field ‘Application Provided Called Parties’ of the MRFC CDR.

11. Acknowledgement of path between AS and UE-2. Now a path between UE-2 and MRFP via AS is established.

12 –13. Request and acknowledgement to establish path between AS and MRFC for UE-3.

14. -15. Path establishment between UE-3 and AS. Same ICID is used as for the path between AS and MRFC for UE-3 (step 12. – 13.).

16. Acknowledgement of path between AS and MRFC for UE-3.

17. The MRFC may send an Charging Data Request[Interim] to report that UE-3 has been connected to the multi-party call.

18. The CDF acknowledges the reception of the data and includes UE-3 in a new field ‘Application Provided Called Parties’ of the MRFC CDR.

19. Acknowledgement of path between AS and UE-3.

20 – 21. Request and acknowledgement to establish path between AS and MRFC for UE-1. Same ICID is used as for the path between UE-1 and AS (step 1.).

22 – 23. Request for multi-party conference with UE-2 and UE-3 is acknowledged to UE 1. Implicit acknowledgement of path UE-1 to AS.

24. Acknowledgement of path between AS and MRFC for UE-1.

25. The MRFC may send an Charging Data Request[Interim] to report that UE-1 has been connected to the Multi-Party call.

26. The CDF acknowledges the reception of the data and includes the field ‘Service Delivery Start Time Stamp’ into the MRFC CDR.

27. – 28. UE-1 acknowledges the multi-party call session establishment.

NOTE: It is in the responsibility of the AS to terminate the sessions existing at the beginning of the multi-party call establishment between UE-1 and UE-2 and between UE-1 and UE-3 (see step 1.) in case of successful multi-party call establishment. This is not shown in the diagram above.

5.2.2.1.11 AS related procedures – AS acting as a redirect server

ASs may support a multitude of services which are not specified in 3GPP standards. Therefore it is not possible to standardise charging flows and procedures for those services. However, for all such services, the AS may apply either event charging, where Charging Data Request [event] messages are generated, or Session Charging, using Charging Data Request [start, stop and interim]. The following clauses depict one example for each of the two scenarios. The first procedure, AS acting as a redirect server, depicts the "event" case, while the second procedure, AS acting as a voice mail server, depicts the "session" case.

Figure 5.2.2.1.11.1 shows the case where an AS acts as a redirect server. In the figure below, UE-1 sets up a session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is returned to UE-1. Finally UE-1 sets up the session towards UE-3.

Figure 5.2.2.1.11.1: Message sequence chart for AS acting as a redirect server

1. Sessions initiated by UE-1 towards UE-2.

2. – 3. Response indicating that session should be redirected towards another number (UE-3).

4. After successful service execution, the AS sends Charging Data Request[Event] to record service specific information in the AS CDR.

5. The CDF acknowledges the reception of the data and creates the AS CDR.

6-7. Response indicating that session should be redirected towards another number (UE-3).

8. Session is initiated by UE-1 towards UE-3.

5.2.2.1.12 AS related procedures – AS acting as a voice mail server

Figure 5.2.2.1.12.1 shows the case where an AS acts as a voice mail server. S-CSCF invokes the AS acting as Voice Mail Server according to procedure as defined in TS 23.218 [203].

Figure 5.2.2.1.12.1: Message sequence chart for AS acting as a mail server

1. AS receives the SIP INVITE from the S-CSCF.

2. AS acknowledges the initiated Voice Mail session by issuing a SIP 200 OK in response to the SIP INVITE.

3. AS sends Charging Data Request[Start] to record start of a voice mail session.

4. The CDF acknowledges the reception of the Charging Data Request[Start] and opens an AS CDR.

5. Voice mail session release is initiated.

6. Upon reception of release message AS sends an Charging Data Request[Stop] to record stop of a session in the AS CDR.

7. The CDF acknowledges the reception of the data and closes the AS CDR.

5.2.2.1.13 AS Related Procedures – AS Acting as a SCC AS

5.2.2.1.13.0 Introduction

Service continuity using SCC AS call flows with alternative "OneChargingSession" option reflected in the different flows description, i.e. a single charging session from SCC AS.

5.2.2.1.13.1 UE originating call (PS only or CS only)

In the flow figure 5.2.2.1.13.1.1, Call-ID #1 is for access leg and Call-ID #2 is for remote leg.

Figure 5.2.2.1.13.1.1: Message sequence chart UE originating call

1. The SCC session is initiated (an SIP INVITE for IMS, a call setup for CS).

2. After processing at CS/PS intermediate nodes, the resulting SIP INVITE is sent to the S‑CSCF

3. The S-CSCF validates the service profile, and invokes any appropriate service logic required for this user.

4. The S-CSCF forwards the SIP INVITE request message to the SCC AS, according to the service origination logic defined by initial Filter Criteria (iFC) in the subscriber profile of the HSS.

5. The SCC call is anchored at the SCC AS in the home IMS Domain upon reception of the SIP Invite (Call-ID# 1).

6-7. The S-CSCF forwards the SIP INVITE request message to the terminating network (Call-ID #2).

8. The response SIP 200 OK is transmitted to the S-CSCF in the Originating network.

9. Upon reception of the final response, the S-CSCF in the originating network sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media component in the S-CSCF CDR.

10-11. The CDF from the Originating network opens a S-CSCF CDR related to the Remote leg and acknowledges the reception of the data.

12. Same as 8 but for SCC AS (Remote leg)

13. Same as 9 but for the SCC AS (Remote leg)

14-15. Same as 10-11 but opening a SCC AS CDR related to the Remote leg

13-14a-15. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media components in the SCC AS CDR for the IMS session (ICID) with access leg and remote leg. The CDF opens a SCC AS CDR related to the IMS session, and acknowledges the reception of the data.

16. Same as 8 but for S-CSCF AS (Access leg)

17. Same as 9 but for the SCC AS (Access leg) .

18-19. Same as 10-11 but opening a SCC AS CDR (Access leg).

Steps 17 to 19 are not applicable for the "OneChargingSession" option.

20. Same as 9 but for the S-CSCF (Access leg)

21-22. Same as 10-11 but opening a S-CSCF CDR (Access leg)

23. The final response to SIP Invite (Call ID #1) is transmitted.

24. The session is set up with CS or PS media.

For IMS Emergency session over PS, the same flow applies in the UE serving Network, between the E-CSCF (instead of S-CSCF) and the EATF (Emergency Access Transfer Function, instead of SCC AS), with E-CSCF and EATF CDRs opened for access and remote legs.

EATF (acting as a B2BUA) performs third party call control and is considered as an AS for the charging description.

5.2.2.1.13.2 UE originating call (PS and CS combined origination)

In the flow figure 5.2.2.1.13.2.1, Call-ID #1 is for PS access leg, Call-ID #1′ for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.2.1: Message sequence chart UE originating call

1. UE‑1 wants to initiate a multimedia session with UE‑2 with speech components carried on CS bearers and non-speech components carried on PS bearers. Therefore the multimedia session is split into two parts, each one corresponding to a separate access leg. UE‑1 initiates the establishment of the first access leg by sending an SIP INVITE request with non-speech media components. The SIP INVITE contains STI information indicating that a second access leg (with the speech component) will be originated from the CS domain.

2. The S‑CSCF executes any service logic as appropriate.

3. The S‑CSCF sends the SIP INVITE to the SCC AS. The SCC AS identifies that this access leg has to be correlated to a subsequent access leg based on the STI information in the SIP INVITE.

4. UE‑1 request to set up call with CS bearer. The called party number is set to an identifier such as a PSI DN, which is used to indicate to the SCC AS that this access leg is to be combined with a PS leg.
The DN is either statically configured on the UE or assigned to the UE by the network upon IMS Registration.

5. After processing at ICS/Interworking nodes, the resulting SIP INVITE is sent to the S‑CSCF.

6. The S‑CSCF executes any service logic as appropriate.

7. The S‑CSCF sends the SIP INVITE to the SCC AS. The SCC AS identifies that this CS leg has to be correlated to a PS leg based on the iFC in the SIP INVITE.

8. After the SCC AS receives both the SIP INVITE requests in step 3 and in step 7, the SCC AS identifies that they are part of the same multimedia session and combines the two access legs of the session by checking the caller’s identity and anchor the combined session.

9-10. The SCC AS sends SIP INVITE to the remote end point for combined session establishment.

11. The SIP 200 OK response is transmitted to the S-CSCF in the Originating network.

12. Upon reception of the final response, the S-CSCF in the originating network sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media component in the S-CSCF CDR.

13-14. The CDF from the Originating network opens an S-CSCF CDR related to the Remote leg and acknowledges the reception of the data.

15. Same as 11 but for SCC AS (Remote leg)

16. Same as 12 but for the SCC AS (Remote leg)

17-18. Same as 13-14 but opening a SCC AS CDR related to the Remote leg

16-17a-18 Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Start] to record start of the SCC AS CDR for the IMS session (ICID) with the CS access leg, PS access leg and the Remote leg. The CDF opens a SCC AS CDR related to the IMS session, and acknowledges the reception of the data.

19. Same as 11 but for S-CSCF (Access leg)

20. Same as 12 but for the SCC AS (Access leg)

21-22. Same as 13-14 but opening a SCC AS CDR for the PS access leg.

Steps 20 to 22 are not applicable for the "OneChargingSession" option.

23. Same as 12 but for the S-CSCF (Access leg)

24-25. Same as 13-14 but opening a S-CSCF CDR for the PS access leg.

26. Same as 11 but for S-CSCF AS (Access leg).

27. Same as 12 but for the SCC AS (Access leg).

28-29. Same as 13-14 but opening a SCC AS CDR for the CS access leg.

Steps 27 to 29 are not applicable for the "OneChargingSession" option.

29. Same as 12 but for the S-CSCF (Access leg)

30-31. Same as 13-14 but opening a S-CSCF CDR for the CS access leg.

32. The final SIP 200 OK response is sent to the UE #1

33. The SIP 200 OK response is sent to the ICS intermediate nodes.

34. The completion of the CS call bearer is done.

5.2.2.1.13.3 UE terminating call (PS only or CS only)

In the flow figure 5.2.2.1.13.3.1, Call-ID #1 is for PS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.3.1: Message sequence chart UE terminating call

1. The SCC session is initiated by UE #2 sending an SIP INVITE to S-CSCF.

2. The S-CSCF validates the service profile, and invokes any appropriate service logic required for this user.

3. The S-CSCF forwards the SIP INVITE request message to the SCC AS, according to the service origination logic defined by initial Filter Criteria (iFC) in the subscriber profile of the HSS.

4. The SCC call is anchored at the SCC AS in the home IMS Domain upon reception of the SIP INVITE (Call ID #2).

5-6-7. The S-CSCF forwards the SIP INVITE request message to the terminating network (Call ID #1). After processing at CS/PS intermediate nodes, the resulting message is sent to UE #1.

8. The response SIP 200 OK is transmitted to CS/PS intermediate nodes.

9. After processing at CS/PS intermediate nodes, the SIP 200 OK message is sent to S-CSCF.

10. Upon reception of the final response, the S-CSCF in the originating network sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media component in the S-CSCF CDR.

11-12. The CDF from the Originating network opens an S-CSCF CDR related to the Access leg and acknowledges the reception of the data.

13. Same as 9 but for SCC AS (Access leg)

14. Same as 10 but for the SCC AS (Access leg)

15-16. Same as 11-12 but opening a SCC AS CDR related to the Access leg

14-15a-16. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media components in the SCC AS CDR for the IMS session (ICID) with access leg and remote leg. The CDF opens a SCC AS CDR related to the IMS session and acknowledges the reception of the data.

17. Same as 9 but for SCC AS (Remote leg)

18. Same as 10 but for the SCC AS (Remote leg) .

19-20. Same as 11-12 but opening a SCC AS CDR (Remote leg).

Steps 18 to 20 are not applicable for the "OneChargingSession" option.

21. Same as 10 but for the S-CSCF (Remote leg)

22-23. Same as 11-12 but opening a S-CSCF CDR (Remote leg)

24. The final response to SIP INVITE (Call ID #2) is transmitted.

5.2.2.1.13.4 UE terminating call (PS and CS combined origination)

In the flow figure 5.2.2.1.13.4.1, Call-ID #1 is for PS access leg, Call-ID #1′ for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.4.1: Message sequence chart UE terminating call

1. UE‑2 sends SIP INVITE to UE‑1 to establish a session with both speech and non-speech components.

2. The S‑CSCF executes any service logic as appropriate.

3. The S‑CSCF sends the SIP INVITE to the SCC AS. The SCC AS identifies that this access leg has to be correlated to a subsequent access leg based on the ST information in the SIP INVITE.

4. The session is anchored at the SCC AS. Based on operator policy and on information indicating that UE‑1 is accessible over both the PS and CS domains, the SCC AS decides to split the session over PS and CS domains. This behaviour is similar to the behaviour of a CSI AS specified in TS 23.279.

5-6. The SCC AS sends SIP INVITE for the non-speech part of the session. The SIP INVITE contains STI information indicating that the speech component will be established from the CS domain.

7-8. The SCC AS sends SIP INVITE for the speech part of the session and the S‑CSCF forwards the SIP INVITE to the ICS/Interworking nodes.

9. The ICS/Interworking nodes set up call to UE‑1 with CS bearer.

10-18. A 200 OK response is sent to the S-CSCF. The speech and non-speech part of the session is established.

11. Upon reception of the response, the S-CSCF in the originating network sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media component in the S-CSCF CDR.

12-13. The CDF from the Originating network opens an S-CSCF CDR related to the PS Access leg and acknowledges the reception of the data.

14. Same as 10 but for SCC AS (Access leg)

15. Same as 11 but for the SCC AS (Access leg)

16-17. Same as 12-13 but opening a SCC AS CDR related to the PS Access leg.

15-16a-17. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Start] to record start of the SCC AS CDR for the IMS session (ICID) with the PS access leg and the Remote leg. The CDF opens the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

19. Upon reception of the response, the S-CSCF in the originating network sends an Charging Data Request[Start] to record SCC call routing and start of a user session/media component in the S-CSCF CDR.

20-21. The CDF from the Originating network opens an S-CSCF CDR related to the CS Access leg and acknowledges the reception of the data.

22. Same as 10 but for SCC AS (Access leg)

23. Same as 11 but for the SCC AS (Access leg)

24-25. Same as 12-13 but opening a SCC AS CDR related to the CS Access leg.

23-24a-25. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Interim] to record modification of the SCC AS CDR for the IMS session (ICID) with the CS access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

26. Same as 10 but for S-CSCF (Remote leg)

27. Same as 11 but for the SCC AS (Remote leg)

28-29. Same as 12-13 but opening a SCC AS CDR for the Remote leg.

Steps 27 to 29 are not applicable for the "OneChargingSession" option.

30. Same as 11 but for the S-CSCF (Remote leg)

31-32. Same as 12-13 but opening a S-CSCF CDR for the Remote leg.

33. The SIP 200 OK response is sent to the UE #2.

5.2.2.1.13.5 Session transfer from PS to CS

In the flow figure 5.2.2.1.13.5.1, Call-ID #1 is for PS access leg, Call-ID #1′ for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.5.1: Message sequence chart UE domain transfer PS access to CS access

The user is engaged in an active multimedia session with UE‑2 via PS access.

1-2. UE‑1 originates a multimedia call in the CS domain including the STN information to request the real time media transfer to CS access.

3. The ICS intermediate Nodes convert the request into IMS SIP format and then forward the converted request to the S‑CSCF.

4. The S‑CSCF invokes the SCC Application as the first AS of any ASs that need to remain in the path of the call after session transfer.

5. The S‑CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

6 The SCC AS analyses the SIP INVITE to derive that the SIP INVITE is a request to transfer a multimedia session with video and voice media components to the PS domain.

7-9. The SCC AS sends a SIP RE-INVITE to the Remote UE to update the media components of the previous dialog. Remote UE answers by a SIP 200 OK message.

10-12. At Remote Leg update the S-CSCF in the originating network sends Charging Data Request[Interim] to record update of a session in the S-CSCF CDR.

13. The S-CSCF answers to the SIP INVITE message in 7.

14-16. At Remote Leg update the SCC AS sends Charging Data Request[Interim] to record update of a session in the SCC AS CDR.

14-15a-16. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Interim] to record modification of SCC AS CDR for the IMS session (ICID) with the new legs configuration (Remote leg and new CS access leg).The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

17. The SCC AS answers to the SIP INVITE message in 5.18-20. Upon generation of the SIP 200 OK response, the SCC AS in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the SCC AS-CDR for Call-ID #1′. The CDF from the originating network opens an AS CDR and acknowledges the reception of the data.

Steps 18 to 20 are not applicable for the "OneChargingSession" option.

21-23. Upon generation of the SIP 200 OK response, the S-CSCF in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the S-CSCF-CDR for Call-ID #1′. The CDF from the originating network opens an S-CSCF CDR and acknowledges the reception of the data.

24. The SIP 200 OK response is sent by the S-CSCF.

25. The SIP 200 OK response is converted by the ICS/Interworking nodes in CS format.

26-28. The UE #1 acknowledges by sending an ACK message to the SCC AS.

29-31. The SCC Application sends BYE request to release the old access leg.

32-34. At session termination the SCC AS sends Charging Data Request[Stop] to record stop of a session and stop of a media component in the SCC AS CDR. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for the Access leg establishment.

Steps 32 to 34 are not applicable for the "OneChargingSession" option.

35-37. The S-CSCF in the originating network sends Charging Data Request[Stop] for closing the S-CSCF CDR related to the initial Access leg. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be performed using the correlation mechanism with the SCC AS CDR for Access leg.

38-40. The UE-1 acknowledges the release of old access leg.

5.2.2.1.13.6 Session transfer from CS to PS

In the flow figure 5.2.2.1.13.6.1, Call-ID #1 is for PS access leg, Call-ID #1′ for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.6.1: Message sequence chart UE domain transfer CS access to PS access

The user is engaged in an active multimedia session with UE‑2 via CS access.

1. UE-1 originates a call in the PS domain including the STI to request the multimedia session transfer to PS access in conjunction with CS access.

2. The session establishment request is routed to the S-CSCF by the P-CSCF.

3. The S‑CSCF invokes the SCC Application as the first AS of any ASs that need to remain in the path of the call after session transfer.

4. The S‑CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

5. The SCC Application analyses the SIP INVITE to derive that the SIP INVITE is a request to transfer a multimedia session with video and voice media components to the PS domain.

6-8. The SCC AS sends a SIP RE-INVITE to the Remote UE to update the media components of the previous dialog. Remote UE answers by a SIP 200 OK message.

9-11. At Access Leg update the S-CSCF in the originating network sends Charging Data Request[Interim] to record update of a session in the S-CSCF CDR.

12. The S-CSCF answers to the SIP INVITE message in 6.

13-15. At Access Leg update the SCC AS sends Charging Data Request[Interim] to record update of a session in the SCC AS CDR.

13-14a-15. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Interim] to record modification of SCC AS CDR for the IMS session (ICID) with the new legs configuration (Remote leg and new PS access leg).The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

16. The SCC AS answers to the SIP INVITE message in 4.

17-19. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the SCC AS-CDR. The CDF from the originating network opens an AS CDR and acknowledges the reception of the data.

Steps 17 to 19 are not applicable for the "OneChargingSession" option.

20-22. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the S-CSCF-CDR. The CDF from the originating network opens an S-CSCF CDR and acknowledges the reception of the data.

23. The S-CSCF answers to the SIP INVITE message in 2.

24-25. The SIP 200 OK is acknowledged.

26-28. The SCC Application sends BYE request to release the old access leg. 29-31 The SCC AS sends Charging Data Request[Stop] for closing the SCC AS CDR related to the original Access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data

Steps 29 to 31 are not applicable for the "OneChargingSession" option.

32-34. The S-CSCF sends Charging Data Request[Stop] for closing the S-CSCF CDR related to the original Access leg. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be performed using the correlation mechanism with the SCC AS CDR for Access leg.

35-37. The UE-1 acknowledges the release of old access leg.

5.2.2.1.13.7 Session transfer from PS to (CS+PS)

In the flow figure 5.2.2.1.13.7.1, Call-ID #1 is for PS2 access leg, Call-ID #1′ for PS1 access leg, Call-ID #1" for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.7.1: Message sequence chart UE domain transfer PS2 access to PS1 and CS access.

1-2. UE-1 originates a call in the PS1 domain including the STI to request the multimedia session transfer to PS1 access in conjunction with CS access.

3. The session establishment request is routed to the S-CSCF by the P-CSCF.

4. The S-CSCF invokes the SCC Application as the first AS of any ASs that need to remain in the path of the call after session transfer.

5. The S-CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

6. The SCC Application analyses the STI and decides to wait for the session transfer request in CS access.

7. UE-1 origins a CS call including STN to indicate to the network that this is a session transfer request.

8. The ICS intermediate Nodes convert the request into IMS SIP format and then forward the converted request to the S-CSCF.

9. The S-CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

10. The SCC Application correlates the two requests and decides to update the remote leg.

11-13. The SCC AS sends a SIP RE-INVITE to the Remote UE to modify the media components of the existing dialog identified in the REFER request.
The SIP RE-INVITE proposes new SDP parameters based on the parameters received from UE-2 in step 6.
When the Remote UE receives the new media parameters, it returns an answer and starts the reception/transmission of these media components.

14-16. At Access Leg update the S-CSCF in the originating network sends Charging Data Request[Interim] to record update of a session in the S-CSCF CDR.

17. The S-CSCF answers to the SIP INVITE message in 11.

18-20. At Access Leg update the SCC AS sends Charging Data Request[Interim] to record update of a session in the SCC AS CDR

18-19a-20. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Interim] to record modification of SCC AS CDR for the IMS session (ICID) with the new PS access leg, new CS access leg and Remote leg.
The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

21. The S-CSCF answers to the SIP INVITE message in 5.

22-24. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the SCC AS-CDR for Call-ID #1′.
The CDF from the originating network opens an AS CDR and acknowledges the reception of the data.

Steps 22 to 24 are not applicable for the "OneChargingSession" option.

25-27. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the S-CSCF-CDR for Call-ID #1′. The CDF from the originating network opens an S-CSCF CDR and acknowledges the reception of the data.

28-29. The S-CSCF accepts session continuity message from the Remote UE by sending a SIP 200 OK response (for the PS1 INVITE message).

30-32. UE-1 sends an ACK response to the SCC AS.

33. The S-CSCF answers to the SIP INVITE message in 9.

34-36. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the SCC AS-CDR for Call-ID #1". The CDF from the originating network opens an AS CDR and acknowledges the reception of the data.

Steps 34 to 36 are not applicable for the "OneChargingSession" option.

37-39. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the S-CSCF-CDR for Call-ID #1". The CDF from the originating network opens an S-CSCF CDR and acknowledges the reception of the data.

40-41. The S-CSCF accepts session continuity message from the Remote UE by sending a SIP 200 OK response (for the CS INVITE message).

42-44. UE-1 sends an ACK response to the S-CSCF.

45. Once acknowledgment has been received for the both leg, the ACK message is sent to the remote UE.

46-48. The SCC Application initiates to release the old access leg.

49-51. The SCC AS sends Charging Data Request[Stop] for closing the SCC AS CDR related to the original Access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

Steps 49 to 51 are not applicable for the "OneChargingSession" option.

52-54. The S-CSCF sends Charging Data Request[Stop] for closing the S-CSCF CDR related to the original Access leg. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be performed using the correlation mechanism with the SCC AS CDR for Access leg.

55-56. The UE answers by a SIP 200 OK message to the S-CSCF.

57. The S-CSCF sends a SIP 200 OK message to the SCC AS the releasing of the old access leg.

5.2.2.1.13.8 Session transfer from (CS+PS) to PS

In the flow figure 5.2.2.1.13.8.1, Call-ID #1 is for PS2 access leg, Call-ID #1′ for CS access leg, Call-ID #1" for PS1 access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.8.1: Message sequence chart UE domain transfer PS2 access and CS access to PS1 access

1-2. UE-1 originates a call in the PS1 domain including the STI to request the multimedia session transfer to PS1 access.

3. The session establishment request is routed to the S-CSCF by the P-CSCF.

4. The S-CSCF invokes the SCC Application as the first AS of any ASs that need to remain in the path of the call after session transfer.

5. The S-CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

6. The SCC Application analyses the STI and decides to update the Remote leg.

7-9. The SCC AS sends a SIP RE-INVITE to the Remote UE to modify the media components of the existing dialog identified in the REFER request.
The SIP RE-INVITE proposes new SDP parameters based on the parameters received from UE-2 in step 6.
When the Remote UE receives the new media parameters, it returns an answer and starts the reception/transmission of these media components.

10-12. At Access Leg update the S-CSCF in the originating network sends Charging Data Request[Interim] to record update of a session in the S-CSCF CDR.

13. The S-CSCF answers to the SIP INVITE message in step 7.

14-16. At Access Leg update the SCC AS sends Charging Data Request[Interim] to record update of a session in the SCC AS CDR.

14-15a-16. Alternatively, when "OneChargingSession", the SCC AS sends an Charging Data Request[Interim] to record modification of SCC AS CDR for the IMS session (ICID) with remote leg and new PS access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

17. The SCC AS answers to the SIP INVITE message in step 5.

18-20. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the SCC AS-CDR. The CDF from the originating network opens an AS CDR and acknowledges the reception of the data.

Steps 18 to 19 are not applicable for the "OneChargingSession" option.

21-23. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an Charging Data Request[Start] to record start of a user session in the S-CSCF-CDR. The CDF from the originating network opens an S-CSCF CDR and acknowledges the reception of the data.

24. The S-CSCF answers to the SIP INVITE message in step 3.

25. The SIP 200 OK message is sent to UE #1.

26-30. UE-1 sends an ACK response to the S-CSCF. The ACK message is sent to the remote UE.

31-33. The source Access Leg 2(which is one of the Access Legs previously established over PS2) is released by the SCC Application in this example, however the UE‑1 may initiate to release the source Access Leg 2.

34-36. The SCC AS sends Charging Data Request[Stop] for closing the SCC AS CDR related to the original Access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

Steps 34 to 36 are not applicable for the "OneChargingSession" option.

37-39. The S-CSCF sends Charging Data Request[Stop] for closing the S-CSCF CDR related to the original PS Access leg. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be performed using the correlation mechanism with the SCC AS CDR for PS Access leg.

40-42. The UE-1 answers to the BYE message in step 33.

43-45. The SCC Application initiates to release the old access leg via CS access in this example, however the UE‑1 may initiate to release the source Access Leg.

46-48. The SCC AS sends Charging Data Request[Stop] for closing the SCC AS CDR related to the original CS Access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the reception of the data.

Steps 46 to 48 are not applicable for the "OneChargingSession" option.

49-51. The S-CSCF sends Charging Data Request[Stop] for closing the S-CSCF CDR related to the original CS Access leg. This CDR may be generated with special handling. One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be performed using the correlation mechanism with the SCC AS CDR for CS Access leg.

52-54. The UE-1 answers to the BYE message in step 43.

5.2.2.1.13.9 IMS emergency session transfer from PS to CS

In the flow figure 5.2.2.1.13.9.1, Call-ID #1 is for PS access leg, Call-ID #1′ for CS access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.9.1: Message sequence chart UE domain transfer PS access to CS access for IMS emergency session.

1-2. UE originates an IMS emergency session transfer towards EATF via I-CSCF.

3. From the received INVITE analysis, the EATF derives a request for transfer of the existing IMS emergency session to the CS domain, and proceeds with switch of access leg communicating with the Remote Leg from Old PS Access Leg to new CS Access Leg.

4-5. The EATF performs the Remote Leg update by sending the SIP RE-INVITE request towards the remote end vie E-CSCF.

6-8 Upon receipt of the SIP 200 OK response, the E-CSCF sends an Charging Data Request[Interim] to record update of the E-CSCF CDR for remote leg Call-ID #2.

9-11 Upon receipt of the SIP 200 OK response, the EATF sends an Charging Data Request[Start] to record start of an EATF CDR for new access leg Call-ID #1′. Alternatively, when "OneChargingSession", the EATF sends an Charging Data Request[Interim] to record modification of EATF CDR for the IMS session (ICID) with new CS access leg. The CDF updates the EATR CDR related to the IMS session and acknowledges the reception of the data.

12-14 Upon receipt of the SIP 200 OK response, the I-CSCF sends an Charging Data Request[Event] to create an I-CSCF CDR for new access leg Call-ID #1′.

15. The SIP 200 OK response is sent towards the UE via ICS/Interworking nodes.

16-17 Upon release of old access leg, the EATF sends an Charging Data Request[Stop] to record stop of the EATF CDR for old access leg Call-ID #1.

Steps 16 to 17 are not applicable for the "OneChargingSession" option.

18-19 Upon release of old access leg, the E-CSCF sends an Charging Data Request[Stop] to record stop of the E-CSCF CDR for old access leg Call-ID #1.

EATF (acting as a B2BUA) performs third party call control and is considered as an AS for the charging description.

5.2.2.1.13.10 Inter-UE transfer triggered by target UE without collaborative session establishment

In the flow figure 5.2.2.1.13.10-1, Call-ID #1 is for source access leg, Call-ID #1′ for target access leg and Call-ID #2 for remote leg.

Figure 5.2.2.1.13.10-1 Message sequence chart Inter-UE transfer triggered by target UE without collaborative session establishment

The user is engaged in an active call session with UE#2 via either PS or CS access. UE#2 is having either PS or CS access (or both).

1. The user decides to transfer the session to UE#2, therefore initiates a call with UE#2 in its current (PS or CS) domain including the STN information to request the transfer of the session to UE#2.

2a. UE#2 originates a call in PS domain including the STN information to initiate Inter-UE transfer

2b. UE#2 originates a call in CS domain including the STN information (Inter-UE STN number) to initiate Inter-UE transfer. The ICS intermediate Nodes convert the request into IMS SIP format.

3. The request is forwarded to the S‑CSCF.

4. The S‑CSCF invokes the SCC Application as the first AS of any ASs that need to remain in the path of the call after session transfer.

5. The S‑CSCF forwards the SIP INVITE to the SCC Application over the ISC interface.

6 The SCC AS analyses the SIP INVITE to derive that the SIP INVITE is a request to transfer a session from UE#1 to UE#2.

7-9. The SCC AS sends a SIP Re-INVITE to the Remote UE to update the media components of the previous dialog. Remote UE answers by a SIP 200 OK message.

10-12. At Remote Leg update the S-CSCF in the originating network sends Charging Data Request[Interim] to record update of a session in the S-CSCF CDR.

13. The S-CSCF answers to the SIP INVITE message in 7.

14-16. At Remote Leg update the SCC AS sends Charging Data Request[Interim] to record update of a session in the SCC AS CDR.

Steps 18 to 20 are not applicable for the "OneChargingSession" option.

24. The SIP 200 OK response is sent by the S-CSCF.

25a. The SIP 200 OK response is forwared to UE#2.

25b. The SIP 200 OK response is converted by the ICS/Interworking nodes in CS format and sent to UE#2.

26a. UE#2 acknowledges the SIP 200 OK message.

26b. UE#2 acknowledges the Connect message.

27-28. The acknowledge from UE#2 is forwarded to the SCC AS.

29-30. The SCC application sends SIP BYE request to release the old access leg.

31a. The SIP BYE is forwarded to UE#1.

31b. The BYE is converted by the ICS/Interworking nodes in CS format and sent to UE#1.

Steps 32 to 34 are not applicable for the "OneChargingSession" option.

38a. UE#1 acknowledges the release of old access leg in PS domain.

38b. UE#1 acknowledges the release of old access leg in CS domain. The ICS intermediate nodes convert the acknowledge into IMS SIP format.

39-40. The acknowledge of the release of old access leg is forwarded to the AS.

5.2.2.1.14 Initiating alternate charged party call

Figure 5.2.2.1.14.1 shows the case where a call with an alternate charged party is successfully initiated.

Figure5.2.2.1.14.1: Successful Initiation of alternate party charging

1. The AS receives a SIP INVITE.

2. After determining that alternate charged party is supported, the AS initiates an Invite with an "Alternate Party Identity" for charging. The method for determination of the alternate charged party includes accessing subscriber data and doing a security assessment.

3. The terminating side issues a SIP 200 OK (Answer), to AS.

4. The AS sends a SIP 200 OK.

5. The AS sends an Charging Data Request[Start] to the CDF.

6. The CDF opens a CDR with the Subscription-ID for the Alternate Charged Party and sends an Charging Data Response to the AS.

7. The session is established.

5.2.2.1.15 Session establishment via IBCF to S-CSCF – IMS initiated

Figure 5.2.2.1.15.1 shows the Charging Data transactions that are required between IBCF, S-CSCF and CDF in each IMS network during session establishment.

Figure 5.2.2.1.15.1: Message sequence chart for IMS initiated session establishment via IBCF

1. The session is originated in Home IMS A, and an SIP INVITE is sent through to Home IMS B via IBCFs.

2. All of the IMS network entities respond with successful SIP 200 OK to the SIP INVITE.

3. Upon reception of the answer message, the IBCFs send an Charging Data Request[Start] in each IMS to record start of a user session and start of a media component in the IBCF and CDRs.

4 The CDF in each IMS acknowledges the reception of the data and opens an IBCF CDR.

5. Upon reception of the answer message, the S-CSCFs send an Charging Data Request[Start] in each IMS to record start of a user session and start of a media component in the and S-CSCF.

6 The CDF in each IMS acknowledges the reception of the data and opens an S-CSCF CDR.

7. The session is established.

5.2.2.1.16 AS related procedures – AS acting as a MMTel AS.

For details on charging at AS acting as an MMTel server, providing service such as CDIV, CONF and TIP/TIR, see the TS 32.275 [35].

5.2.2.1.17 Session establishment via IBCF to a third party AS providing tariff information in real time (RTTI)

Figure 5.2.2.1.17.1 shows the Charging Data transactions that are required between S-CSCF, IBCF and CDF, in each IMS network, during session establishment. It represents a charging interconnect scenario where the third party AS (located in another network) provides e.g. value-added service and real time tariff information according to TS 29.658 [206].

Editor’s Note: The interconnect scenario between IMS network and PSTN (involving MGCF rather than IBCF) is FFS.

Figure 5.2.2.1.17.1: Message sequence chart for IMS initiated session establishment with a 3^rd party AS providing Real-Time Tariff Information (RTTI)

1. The session is initiated.

2. The destination (third party AS) answers with successful SIP 200 OK to the SIP INVITE. The third party AS includes a real time tariff information within the SIP 200OK response.

3. Upon reception of the final response, the S-CSCF sends an Charging Data Request[Start] to record start of a user session and start of a media component in the S-CSCF.

4 The CDF in each IMS network acknowledges the reception of the data and opens an S-CSCF CDR.

5. Upon reception of the SIP 200 OK message, the IBCFs send an Charging Data Request[Start] in each IMS to record start of a user session and start of a media component in the IBCF.

6 The CDF in each IMS acknowledges the reception of the data and opens an IBCF CDR.

5.2.2.1.18 Third party AS providing tariff information in real time (RTTI) during the session

Figure 5.2.2.1.18.1shows the Charging Data transactions that are required between S-CSCF, IBCF and CDF, in each IMS network, when a third party AS (located in another network) involved in the session provides e.g. value-added service and real time tariff information according to TS 29.658 [206] during the session.

Figure 5.2.2.1.18.1: Message sequence chart for third party AS providing tariff information in real time (RTTI) during the session

1. The third party AS includes an RTTI within a SIP INFO and sends the message to the originating party.

2. Upon reception of the SIP INFO embedding RTTI, the S-CSCF sends an Charging Data Request[Interim] to record tariff information in the CDR.

3. The CDF acknowledges the reception of the data and updates the S-CSCF CDR.

4 Upon reception of the SIP INFO embedding RTTI, the IBCF sends an Charging Data Request[Interim] to record tariff information in the CDR.

5. The CDF acknowledges the reception of the data and updates the IBCF-CDR.

6. Upon reception of the SIP INFO embedding RTTI, the IBCF sends an Charging Data Request[Interim] to record tariff information in the CDR.

7. The CDF acknowledges the reception of the data and updates the IBCF-CDR.

8. Upon reception of the SIP INFO embedding RTTI, the S-CSCF sends an Charging Data Request[Interim] to record tariff information in the CDR.

9. The CDF acknowledges the reception of the data and updates the S-CSCF CDR.

5.2.2.1.19 Support of Optimal Media Routing (OMR)

5.2.2.1.19.0 Introduction

Optimal Media Routing (OMR) relies on IMS-ALG function enhancement, used by some IMS Nodes as described in TS 23.228 [201] Annex Q, when performing media functions at transport level such as firewall or NAT, or application level such as transcoding. The purpose of OMR is to identify and remove unnecessary media functions from the media path for each media stream associated to a session. The OMR procedures are applicable to the following IMS entities having IMS-ALG function used in a B2BUA mode:

– P-CSCF for support of NAT for signalling and media (with IMS-ALG/IMS-AGW model as described in TS 23.228 [201]) Annex G);

– IBCF for border Control Functions towards other IMS/SIP Networks (with IBCF/TrGW model as described in TS 23.228 [201] Annex I);

– Any AS performing as a B2BUA controlling media resources.

Although the different TS 23.228 [201] scenarios mainly address the IBCF/TrGW, they are also applicable to P-CSCF/ IMS-AGW, except for transcoding function which relates to IBCF only. Consequently, in the different flows, the "GW" stands for TrGW or IMS-AGW, according to the situation.

The following flows focus on one IMS Node behaviour, embedding such IMS-ALG function supporting OMR, when involved in some of OMR scenarios described in TS 23.228 [201] Annex Q.

Each media line of the same session can be applied with separate OMR decision (i.e. different optimised paths), however, for simplification, only one media is assumed in the following call flows.

In the Figure, the "Originating side" may be an Originating UA or another IMS-ALG in the same IMS Network, or another IMS Network, and the "Destination side" may be a Terminating UA or another IMS-ALG in the same IMS Network, or another IMS Network.

5.2.2.1.19.1 IMS-ALG related procedures for OMR – Session establishment and IMS-ALG bypasses its local GW

Figure 5.2.2.1.19.1.1 shows the session establishment with SDP offer/answer exchange from Originating side towards a Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR, and OMR results in IMS-ALG bypasses its local GW.

Figure 5.2.2.1.19.1.-1: Message sequence chart for session establishment with IMS-ALG supporting OMR and IMS-ALG bypasses its local GW due to OMR process.

1. IMS-ALG receives an SIP INVITE with SDP offer-inc (call-ID#-inc) from Originating side, containing the transport address allocated in realm R1 by the Originating side for the media on incoming leg, and potential OMR information from prior user plane segments.

2. IMS-ALG determines the outgoing IP realm (R2) is different from the incoming IP realm (R1) and interacts with a GW in order to allocate a local transport address for the media on outgoing leg, in realm R2.

3. IMS-ALG generates SIP INVITE towards Destination side (call-ID#-out), with a new SDP offer-out including such local transport address, and also OMR extensions (for the segment locally handled, along with those received from prior user plane segments) for further OMR decisions.

4. The destination side answers with SIP 200 OK and SDP answer-out, with the transport address allocated by the destination side for the media on outgoing leg, as result of OMR processing (based on OMR information provided in step 3). This transport address is in realm R1, thus identifying the local GW to be bypassed (i.e. same IP realm as in step 1), and also identifying use of a different IP realm from the default one (i.e. R2).

5. The Local GW is de-allocated (release of resource allocated in step 2 in realm R2).

6. IMS-ALG forwards the SDP answer-inc for the media on incoming leg, with this transport address received in step 4.

7. IMS-ALG sends Charging Data Request[Start] to record start of session with "Local GW Not Inserted" and "IP realm Not Default" indications for the media.

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data.

10. A user plane connection is now established in realm R1 without GW insertion for the media.

5.2.2.1.19.2 IMS-ALG related procedures for OMR – session establishment and alternate IP realm is selected

Figure 5.2.2.1.19.2.1 shows the session establishment with SDP offer/answer exchange from Originating side towards Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR, and OMR results in alternate IP realm selection (i.e. not the default IP realm) for the media.

Figure 5.2.2.1.19.2.1: Message sequence chart for session establishment with IMS-ALG supporting OMR, and alternate realm is selected due to OMR process.

2. IMS-ALG determines the outgoing IP realm (R2) is different from the incoming IP realm (R1) and interacts with a GW1 in order to allocate a local transport address for the media on outgoing leg, in realm R2. IMS-ALG additionally interacts with GW2 in order to allocate an alternate local transport address for the media in realm R3.

3. IMS-ALG generates SIP INVITE towards Destination side (call-ID#-out), with a new SDP offer-out including such local transport addresses, and also OMR extensions (for the segment locally handled, along with those received from prior user plane segments) for further OMR decisions.

4. The destination side answers with SIP 200 OK and SDP answer-out, with the transport address allocated by the destination side for the media on outgoing leg, as result of OMR processing (based on OMR information provided in step 3).This transport address is in realm R3, thus identifying the local GW2 to be retained, and also identifying use of a different IP realm from the default one (i.e. R2).

5. The GW1 is de-allocated (release of resource allocated in step 2 for realm R2), and interaction occurs with GW2 to maintain the user plane connection via R3.

6. IMS-ALG1 forwards the SDP answer-inc, with the transport address allocated by the GW2 in realm R1, for the media on incoming leg.

7. IMS-ALG sends Charging Data Request[Start] to record start of session with "Local GW Inserted" and "IP realm Not Default" indications for the media.

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data.

10a-b. A user plane connection is now established in realm R1 up to the GW2, and in realm R3 from the GW2 for the media.

5.2.2.1.19.3 IMS-ALG related procedures for OMR – mid-session procedure

Figure 5.2.2.1.19.3.1 shows a scenario when a new SDP offer/answer exchange due to UE generating a SIP (rE‑)iNVITE or SIP UPDATE in mid-session in order to add a media component , and the OMR procedures is processed for this new media, with same situation as in clause 5.2.2.1.19.1 (IMS-ALG bypasses its local GW).

This scenario also applies for situations where a (rE‑)iNVITE or a SIP UPDATE is issued for updating a media and the OMR procedures is processed again, changing the established media path.

Figure 5.2.2.1.19.3.1: Message sequence chart for mid-session procedure with IMS-ALG supporting OMR, IMS-ALG bypasses its GW due to OMR process for the added media.

The same steps described in clause 5.2.2.1.19.1 apply, with following exceptions:

1 and 3. A SIP RE-INVITE instead of SIP INVITE

7. IMS-ALG sends Charging Data Request[Interim] to record update of session with "Local GW Not Inserted" and "IP realm Not Default" indications for the media.

8-9. The CDF updates the session CDR for the IMS Node and acknowledges the reception of the data.

5.2.2.1.19.4 IMS-ALG related procedures for OMR – transcoding

5.2.2.1.19.4.0 Introduction

As described in TS 23.228 [201] Annex Q, transcoding is also part of OMR process.

The following flows 5.2.2.1.19.4.1 show session establishment with SDP offer/answer exchange from Originating side towards a Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR with transcoder inserted by this IMS node.

Although transcoding aspect is part of the same SDP offer/answer different exchanges described in clause 5.2.2.1.19.1 to clause 5.2.2.1.19.3, therefore combined in OMR process, it is reflected here through dedicated flows for simplification.

These procedures apply to IBCF/TrGW only.

5.2.2.1.19.4.1 IMS-ALG Related Procedures for OMR – transcoder provided by IMS-ALG

The flow in figure 5.2.2.1.19.4.1.1 describes the situation where IMS-ALG allocates a transcoder for offering an additional transcoding option, and this transcoder is selected.

Figure 5.2.2.1.19.4.1.1: Message sequence chart for Session establishment with transcoder offered by IMS-ALG is inserted

1. IMS-ALG receives an SIP INVITE with SDP offer-inc (call-ID#-inc) from Originating side, containing a codec-list-inc in the SDP offer, and potential OMR information from prior user plane segments based on an Operator’s configuration.

2. IMS-ALG interacts with TrGW for transcoder allocation for the purpose of offering an additional codec "codec-out".

3. IMS-ALG generates INVITE towards Destination side (call-ID#-out), the SDP offer-out containing the new codec-list-out (i.e. codec-list-inc enriched with "codec-out"), and also OMR extensions (for transcoding options associated to different segments).

4. The destination side answers with SIP 200 OK and SDP answer-out with the selected codec which is the additional one offered by IMS-ALG (i.e. codec-out).

5. Interaction occurs with TrGW for media configuration with codec-out for the outgoing leg and with codec-inc for the incoming leg (codec-inc is selected by IBCF from the codec-list-inc received in step 1).

6. IMS-ALG forwards the SDP answer-inc for the incoming leg, with this codec-inc.

7. IMS-ALG sends Charging Data Request[Start] to record start of session with "Transcoder Inserted" indication for the media.

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data.

5.2.2.1.19.4.2 IMS-ALG related procedures for OMR – transcoder offered by IMS-ALG but not selected

The fflow in figure 5.2.2.1.19.4.2.1 describes the situation where IMS-ALG allocates a transcoder for offering an additional transcoding option, and this transcoder is not selected.

Figure 5.2.2.1.19.4.2.1: Message sequence chart for session establishment with transcoder offered by IMS-ALG is not selected

2. IMS-ALG interacts with TrGW for transcoder allocation for the purpose of offering additional codec "codec-out".

3. IMS-ALG generates SIP INVITE towards Destination side (call-ID#-out), the SDP offer-out containing the new codec-list-out (i.e. codec-list-inc enriched with "codec-out"), and also OMR extensions (for transcoding options associated to different segments).

4. The destination side answers with SIP 200 OK and SDP answer-out with the selected codec (codec-inc), belonging to the codec-list-inc received in step 1 (original offer).

5. Therefore, transcoding is not needed, and TrGW is de-allocated.

6. IMS-ALG forwards the SDP answer-inc for the incoming leg, with this codec-inc.

7. IMS-ALG sends Charging Data Request[Start] to record start of session with "Transcoder Not Inserted" indication for the media.

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data.

5.2.2.1.20 AS acting as a B2BUA – single charging session

Figure 5.2.2.1.20.1 shows the case where an AS acts as a B2BUA, and a single offline charging session is created for the established dialogs ("OneChargingSession" option)

Figure 5.2.2.1.20.1: Message sequence chart for AS acting as a B2BUA with single charging session

1. AS receives the SIP INVITE from Incoming side (Call-ID#inc) containing ICID.

2. AS acting as a B2BUA generates SIP INVITE towards Outgoing side (Call-ID#out) with the same ICID as received in step 1.

3. SIP 200 OK is received in response to the SIP INVITE (Call-ID#out).

4. SIP 200 OK is sent in response to the SIP INVITE (Call-ID#inc).

5. AS sends Charging Data Request[Start] to record start of a session, provided with ICID and information associated to both Call-ID#inc and Call-ID#out.

6. The CDF acknowledges the reception of the Charging Data Request[Start] and opens a AS CDR.

7. AS receives a mid-session (e.g. in order to modify media component(s)) SIP RE-INVITE or SIP UPDATE from Incoming side (Call-ID#inc) for the IMS session (ICID).

8. AS generates SIP RE-INVITE or SIP UPDATE towards Outgoing side (Call-ID#out)

9-10. AS sends SIP 200 OK (Call-ID#inc) towards Incoming side, when SIP 200 OK (Call-ID#out) response is received from Outgoing side.

11. AS sends an Charging Data Request[Interim] to record changes associated to Call-ID#inc or/and Call-ID#out (e.g. changed media component(s)) in the AS CDR for the IMS session (ICID).

12. The CDF acknowledges the reception of the data and updates the AS CDR.

13. AS receives BYE from Incoming side (Call-ID#inc)

14. AS sends BYE towards Outgoing side (Call-ID#out)

15. AS sends an Charging Data Request[Stop] to record stop of a session in the AS CDR for the IMS session (ICID).

16. The CDF acknowledges the reception of the data and closes the AS CDR.

17-18. AS sends SIP 200 OK (Call-ID#inc) towards Incoming side, when SIP 200 OK (Call-ID#out) response is received from Outgoing side.

5.2.2.1.21 Session establishment for roaming architecture for voice over IMS with local breakout

Figure 5.2.2.1.21.1 shows the Charging Data transactions initiated by the P-CSCF, S-CSCF, IBCF, and TRF towards the CDF that are required for a roaming architecture for voice over IMS with local breakout in each IMS network during session establishment. This example pertains to the flow in Annex M.3.1.3 in TS 23.228 [201] in which loopback and OMR procedures are applied between the visited network and the home network serving UE A.

Figure 5.2.2.1.21.1: Message sequence chart for roaming architecture for voice over IMS with local breakout with "VPLMN routing" and TRF

1. The session initiation is acknowledged by the SIP 200 OK by the termination side and received by the IBCF in the Visited Network A.

1a. IBCF sends Charging Data Request[Start] to record start of session with "Local GW Inserted" indication and with information on the non-roaming NNI 5 used for interconnection towards the terminating network.

1b. The CDF acknowledges the reception of the data and opens an IBCF CDR.

2. The Visited Network A TRF performs the loopback procedure and the session acknowledgement is routed towards the Home network through an IBCF.

2a. TRF sends Charging Data Request[Start] to record start of session and indicating loopback routing from the roaming NNI.

2b. The CDF acknowledges the reception of the data and opens a TRF CDR.

2c. IBCF sends Charging Data Request[Start] to record start of session with "Local GW Not Inserted" indication and with information on the roaming NNI 4 interconnecting to the intermediate network for the loopback path.

2d. The CDF acknowledges the reception of the data and opens an IBCF CDR.

2e. IBCF sends Charging Data Request[Start] to record start of session with "Local GW Not Inserted" indication and with information on the roaming NNI 3 interconnecting to the intermediate network for the loopback path.

2f. The CDF acknowledges the reception of the data and opens an IBCF CDR.

3. The S-CSCF in the Home Network A routes the session acknowledgement towards the Visited Network A through an IBCF.

3a. S-CSCF sends Charging Data Request[Start] to record start of session and indicating loopback routing to the roaming NNI.

3b. The CDF acknowledges the reception of the data and opens an IBCF CDR.

3c. IBCF sends Charging Data Request[Start] to record start of session with "Local GW Not Inserted" indication and with information on the roaming NNI 2 interconnecting to the intermediate network for the non-loopback path.

3d. The CDF acknowledges the reception of the data and opens an IBCF CDR.

3e. IBCF sends Charging Data Request[Start] to record start of session with "Local GW Not Inserted" indication and with information on the roaming NNI 1 interconnecting to the intermediate network for the non-loopback path.

3f. The CDF acknowledges the reception of the data and opens an IBCF CDR.

3g. P-CSCF sends Charging Data Request[Start] to record start of session.

3h. The CDF acknowledges the reception of the data and opens an IBCF CDR.

5.2.2.1.22 Service continuity using ATCF

5.2.2.1.22.0 Introduction

Service continuity using ATCF call flows with alternative "OneChargingSession" option reflected in the different flows description, i.e. a single charging session from ATCF.

5.2.2.1.22.1 UE originating call (CS only) through ATCF

In the flow figure 5.2.2.1.22.1.1, Call-ID #1 is for serving leg and Call-ID #2 is for home leg of CS access leg.

Figure 5.2.2.1.22.1.1: Message sequence chart UE originating call (CS only) through ATCF

1. The SCC session is initiated by UE#1 sending a Call Setup.

2. After processing at CS/PS intermediate nodes, the resulting SIP INVITE goes through the ATCF in the UE#1 serving network.

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it.

4. The ATCF create an SIP INVITE request message and send it to the UE#1 Home Network SCC AS.

5. The call setup proceeds and is routed to the remote UE-2.

6-7. On response SIP 200 OK from the remote UE#2, response SIP 200 OK is transmitted to UE#1 serving network.

8. Upon reception of the final response, the ATCF sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR for the IMS session.

9-10. The CDF from the Serving network opens an ATCF CDR for the home leg (Call-ID#2) and acknowledges the reception of the data.

9a-10. Alternatively, when "OneChargingSession", the CDF opens an ATCF CDR related to the IMS session, with serving leg and home leg, and acknowledges the reception of the data.

11-12. The final response to SIP INVIT (Call ID #1) is transmitted.

13-15. Same as 8-9-10 but opening a ATCF CDR for the serving leg (Call-ID#1).

Steps 13 to 15 are not applicable for the "OneChargingSession" option.

5.2.2.1.22.1A UE originating call (PS only) through ATCF

Figure 5.2.2.1.22.1A.1: Message sequence chart UE originating call (PS only) through ATCF

1. The SCC session is initiated by UE#1 sending an SIP INVITE.

2. After processing at P-CSCF, the resulting SIP INVITE goes through the ATCF in the UE#1 Visited Network.

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it.

4. The ATCF forwards the SIP INVITE request message to the UE#1 Home Network SCC AS.

5. The call setup proceeds and is routed to the remote UE#2.

6-7 On response SIP 200 OK from the remote UE#2, response SIP 200 OK is transmitted to UE#1 Visited Network.

8. Upon reception of the final response, the ATCF sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR for the IMS session.

9-10. The CDF from UE#1 Visited Network opens an ATCF CDR and acknowledges the reception of the data.

11-12. The final response to SIP INVITE is transmitted.

5.2.2.1.22.2 UE terminating call (CS only) through ATCF

In the flow figure 5.2.2.1.22.2.1, Call-ID #1 is for serving leg and Call-ID #2 is for home leg.

Figure 5.2.2.1.22.2.1: Message sequence chart UE terminating call (CS only) through ATCF

1. The SCC session is initiated by UE #2 sending an SIP INVITE towards UE-1.

2. The call setup proceeds and is routed to the UE-1.

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it.

4. The ATCF create an SIP INVITE request message and send it to the CS/PS intermediate nodes.

5. After processing at CS/PS intermediate nodes, the resulting message is sent to UE #1.

6. The response is transmitted to CS/PS intermediate nodes.

7. After processing at CS/PS intermediate nodes, the SIP 200 OK message is sent to ATCF.

8. Upon reception of the final response, the ATCF in the terminating network sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR.

9-10. The CDF from the Terminating serving network opens an ATCF CDR for the serving leg (Call ID #1) and acknowledges the reception of the data.

9a-10 Alternatively, when "OneChargingSession", the CDF opens a ATCF CDR related to the IMS session (ICID) with serving leg and home leg, and acknowledges the reception of the data.

11-12. The final response to SIP INVITE (Call ID #2) is transmitted.

13-15. Same as 8-9-10 but for the home leg (Call ID #2).

Steps 13 to 15 are not applicable for the "OneChargingSession" option.

5.2.2.1.22.2A UE terminating call (PS only) through ATCF

Figure 5.2.2.1.22.2A.1: Message sequence chart UE terminating call (PS only) through ATCF

1. The SCC session is initiated by UE #2 sending an SIP INVITE towards UE#1.

2. The call setup proceeds and is routed to the UE#1.

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it.

4. The ATCF forwards the SIP INVITE request message to the P-CSCF.

5. After processing at P-CSCF, the resulting message is sent to UE #1.

6. The response is transmitted to P-CSCF.

7. After processing at P-CSCF, the SIP 200 OK is sent to ATCF.

8. Upon reception of the final response, the ATCF sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR.

9-10. The CDF from UE#1 Visited Network opens an ATCF CDR and acknowledges the reception of the data.

11-12. The final response to SIP INVITE is transmitted.

5.2.2.1.22.3 UE session transfer PS to CS using ATCF

In the flow figure 5.2.2.1.22.3.1, Call-ID #1 is for PS access leg, Call-ID #1′ for serving leg of CS access leg and Call-ID #2′ for home leg of CS access leg.

Figure 5.2.2.1.22.3.1: Message sequence chart UE session transfer PS to CS using ATCF

1. UE has an ongoing session under PS with media anchored in ATGW, and interactions between UE, RAN, MME/SGSN and MSC take place for session transfer to CS.

2. MSC server sends the resulting SIP INVITE towards the ATCF in the UE#1 serving network.

3. The media session is anchored in ATGW: the ATCF updates the ATGW with new CS access leg resource.

4. The ATCF sends SIP 200 OK answer to MSC server for switching the media path.

5-7. the ATCF sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR for the serving leg of new CS access leg.

5-6a-7. Alternatively, when "OneChargingSession", the ATCF sends an Charging Data Request[Interim] to record modification of the ATCF CDR with the serving leg of new CS access leg. The CDF updates ATCF CDR related to the IMS session, with new serving leg, and acknowledges the reception of the data.

8. ACK from MSC server to ATCF

9. The ATCF creates and sends a SIP INVITE request via a new dialog to the SCC AS for indicating the transfer has taken place.

10. The SCC AS sends a SIP 200 OK confirmation response to the ATCF containing SDP answer stored during the original session establishment procedure.

11-13. The ATCF sends an Charging Data Request[Start] to record start of a user session/media component in the ATCF CDR for home leg of new CS access leg.

11-12a-13 Alternatively, when "OneChargingSession", the ATCF sends an Charging Data Request[Interim] to record modification of the ATCF CDR with the home leg of new CS access leg. The CDF updates ATCF CDR related to the IMS session, with new home leg, and acknowledges the reception of the data.

14. The ATCF acknowledges the SIP 200 OK.

15, 19-20 The SCC AS terminates the old PS access leg, by sending a SIP BYE request.

16-18. The ATCF sends an Charging Data Request[Stop] to close the ATCF CDR for the old PS access leg (conducted for both serving and home leg of the old PS access leg if flow 5.2.2.1.22.4 precedes for the same session).

Steps 16 to 18 are not applicable for the "OneChargingSession" option.

5.2.2.1.22.4 UE session transfer CS to PS using ATCF

In the flow figure 5.2.2.1.22.4.1, Call-ID#1 for serving leg of old CS access leg and Call-ID#2 for home leg of old CS access leg, Call-ID#1′ is for serving leg of new PS access leg, and Call-ID#2′ is for home leg of new PS access leg.

Figure 5.2.2.1.22.4.1: Message sequence chart UE session transfer CS to PS using ATCF

1. UE has an ongoing session under CS with media anchored in ATGW, and interactions between UE, RAN, MME/SGSN and MSC take place for session transfer to PS.

2. Transfer preparation procedure between MSC server and ATCF, the MSC interacts with UE for handover.

3. The MSC server sends a SIP INFO request containing a session transfer preparation to the ATCF to instruct the ATCF that media should be switched to the new access leg.

4. The ATCF sends SIP 200 OK answer to MSC server for switching the media path.

5-6. UE A sends an SIP INVITE request towards the ATCF to move the session control to the PS access.

7-11. The ATCF sends a SIP 200 OK response to the UE.

8-10. The ATCF sends an Charging Data Request[Start] to record start of a user session in the ATCF CDR for the serving leg of the new PS access leg.

8-9a -10. Alternatively, when "OneChargingSession", the ATCF sends an Charging Data Request[Interim] to record modification of the ATCF CDR with the serving leg of new PS access leg. The CDF updates ATCF CDR related to the IMS session, with new serving leg, and acknowledges the reception of the data.

12-13. UE acknowledges the SIP 200 OK.

14. The ATCF creates and sends SIP INVITE request via a new dialog to the SCC AS for indicating the transfer has taken place.

15. The SCC AS sends a SIP 200 OK confirmation response to the ATCF containing SDP answer stored during the original session establishment procedure.

16-18. The ATCF sends an Charging Data Request[Start] to record start of a user session in the ATCF CDR for the home leg of the new PS access leg.

16-17a -18. Alternatively, when "OneChargingSession" , the ATCF sends an Charging Data Request[Interim] to record modification of the ATCF CDR with the home leg of new PS access leg. The CDF updates ATCF CDR related to the IMS session, with new home leg, and acknowledges the reception of the data.

20, 27 The SCC AS terminates the old CS access leg, by sending a SIP BYE request.

21-23. The ATCF sends an Charging Data Request[Stop] to close the ATCF CDR for the serving leg of old CS access leg.

24-26. The ATCF sends an Charging Data Request[Stop] to close the ATCF CDR for the home leg of old CS access leg.

Steps 21 to 26 are not applicable for the "OneChargingSession" option.

5.2.2.2 Message flows – error cases and scenarios

5.2.2.2.0 Introduction

This clause describes various error cases and how these should be handled. The error cases are grouped into the following categories:

 Failure in SIP related procedures:

– Session related error scenarios;

– Session unrelated error scenarios.

 Errors in Charging Data Transfer related procedures.

5.2.2.2.1 Session related SIP procedures- reception of SIP error messages

A SIP session is closed abnormally by the reception of a SIP BYE message indicating the reason for such termination.

In this case, an Charging Data Request[stop] message that includes an appropriate error indication is sent.

5.2.2.2.2 Session related SIP procedures – SIP session failure

All nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to maintain the session, this IMS node will generate a SIP BYE message towards both ends of the connection.

The node that sent the BYE to trigger session termination identifies the cause of the failure in the Charging Data Request [stop] towards the CDF. All other nodes, i.e. those that receive the SIP BYE, are not aware of an error, and therefore they treat this situation as any normal SIP session termination.

5.2.2.2.3 Session unrelated SIP procedures

As described in clause 5.1.2.1.2, a session unrelated SIP procedure may either be completed with the reception of a SIP 200 OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the Charging Data Request[event] sent towards the CDF includes an appropriate error indication.

5.2.2.2.4 CDF connection failure

The CDF connection failure mechanism is specified in TS 32.299 [50] clause 6.1.3.1.

5.2.2.2.5 No reply from CDF

The mechanism when no reply from CDF, is specified in TS 32.299 [50] clause 6.1.3.2.

5.2.2.2.6 Duplicate detection

The duplicate detection mechanism is specified in TS 32.299 [50] clause 6.1.3.3.

5.2.2.2.7 CDF detected failure

The CDF detected failure mechanism on expected Charging Data Requests for a particular SIP session is specified in TS 32.299 [50] clause 6.1.3.4.