B.3 IMS Session Modification
29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS
B.3.1 Provisioning of service information
This clause covers the provisioning of service information at IMS session modification both at the originating and terminating side.
In figure B.3.1.1 the P-CSCF derives the provisioning of service information to the PCRF from the SDP offer/answer exchange.
Figure B.3.1.1: Provisioning of service information at IMS session modification
1. The P-CSCF receives the SDP parameters defined by the originator within an SDP offer in SIP signalling.
2. The P-CSCF identifies the relevant changes in the SDP.
3. The P-CSCF forwards the SDP offer in SIP signalling.
4. The P-CSCF gets the negotiated SDP parameters from the terminating side through SIP signalling interaction.
5. The P-CSCF identifies the relevant changes in the SDP.
6. The P-CSCF sends a Diameter AAR for an existing Diameter session and includes the derived updated service information.
7. The PCRF stores the received updated session information and identifies the affected established IP-CAN Session(s).
8. The PCRF answers with a Diameter AAA.
9. If the P-CSCF did not request access network information in step 6, the P-CSCF forwards the SDP answer in SIP signalling.
10. The PCRF executes interactions according to figure 4.3.1.1.1. Due to the updated service information, this step may imply provisioning of PCC/QoS rules or the need to enable or disable IP Flows (see clauses B.3.2 and B.3.3, respectively).
11. If the P-CSCF requested access network information in step 6, the PCRF forwards the access network information received in step 10 in a Diameter RAR.
12. If step 11 occurs, the P-CSCF acknowledges the receipt of Diameter RAR.
13. If step 11 occurs, the P-CSCF forwards the SDP answer and adds the access network information as the network provided location information to the corresponding SIP message.
Optionally, the provisioning of service information may be derived already from the SDP offer to enable that a possible rejection of the service information by the PCRF is obtained by the P-CSCF in time to reject the service with appropriate SIP signalling or to enable pre-authorization for a UE terminated IMS session establishment with UE initiated resource reservation. This is described in figure B.3.1.2.
Figure B.3.1.2: Provisioning of service information derived from SDP offer and answer at IMS session modification
1. The P-CSCF receives an SDP offer in SIP signalling for an exiting SIP dialogue.
2. The P-CSCF identifies the relevant changes in the SDP and extracts the corresponding service information.
3. The P-CSCF forwards the derived service information to the PCRF by sending a Diameter AAR over the existing Rx Diameter session for the corresponding SIP session. It indicates that the service information that the AF has provided to the PCRF is preliminary and needs to be further negotiated between the two ends.
4. The PCRF checks and authorizes the session information, but does not provision PCC/QoS rules at this stage.
5. The PCRF replies to the P-CSCF with a Diameter AAA.
6. If the UE initiates a bearer resource modification request, the PCRF provides the PCEF/BBERF with PCC/QoS rules according to figure 4.3.1.1.1 based on the SDP offer.
NOTE: Step 6 is not applicable for IMS Emergency Sessions.
7. The P-CSCF forwards the SDP offer in SIP signalling.
8. The P-CSCF receives the negotiated SDP parameters within an SDP answer in SIP signalling from the terminating side.
9. The P-CSCF identifies the relevant changes in the SDP and extracts the corresponding service information.
10. The P-CSCF sends a Diameter AAR for an existing Diameter session and includes the derived updated service information.
11. The PCRF answers with a Diameter AAA.
12. The PCRF interacts with the GW according to figure 4.3.1.1.1. This step may imply provisioning of PCC/QoS rules and authorized QoS. The PCRF may need to enable or disable IP Flows (see clauses B.3.2 and B.3.3, respectively) due to the updated service information.
13. If the P-CSCF did not request access network information in step 3 or 10, the P-CSCF forwards the SDP answer in SIP signalling. This step is executed in parallel with step 12.
14. If the P-CSCF requested access network information in step 3 or 10, the PCRF forwards the access network information received in step 12 in a Diameter RAR.
15. If step 14 occurs, the P-CSCF acknowledges the receipt of Diameter RAR.
16. If step 14 occurs, the P-CSCF forwards the SDP answer and adds the access network information as the network provided location information to the corresponding SIP message.
B.3.2 Enabling of IP Flows
The PCRF makes a final decision to enable the allocated QoS resource for the authorized IP flows of the media component (s) if the QoS resources are not enabled at the time they are authorized by the PCRF or if the media IP flow(s) previously placed on hold are resumed, i.e. the media IP flow(s) of the media component that was placed on hold at the time of the resource authorization or at a later stage is reactivated (with SDP direction sendrecv, sendonly, recvonly or none direction).
The Enabling of IP Flows procedure is triggered by the P-CSCF receiving any 2xx success response to an INVITE request or a 2xx success response to an UPDATE request within a confirmed dialogue that is not embedded as part of another INVITE Transaction (in both cases a 200 OK response is usually received). When receiving such responses, the PCRF shall take the SDP direction attribute in the latest received SDP (either within the 2xx success or a previous SIP message) into account when deciding, which gates shall be opened:
– For a unidirectional SDP media component, IP flows in the opposite direction shall not be enabled.
– For an inactive SDP media component, no IP flows shall be enabled.
Figure B.3.2.1 is applicable to the Mobile Originating (MO) side and the Mobile Terminating (MT) side.
Figure B.3.2.1: Enabling of IP Flows
1. The P-CSCF receives the 2xx Success message complying with the conditions specified in the paragraphs above.
2. The P-CSCF sends a Diameter AAR message to the PCRF, requesting that gates shall be opened.
3. The PCRF approves the enabling of IP flows and PCRF updates flow status of affected PCC rules.
4 The PCRF sends a Diameter AAA to the P-CSCF.
5 The P-CSCF forwards the 2xx Success message.
6. The PCRF executes interactions according to figure 4.3.1.1.1. This step implies opening the ‘gates’ by updating the flow status of PCC rules.
B.3.3 Disabling of IP Flows
The “Disabling of IP Flows” procedure is used when media IP flow(s) of a session are put on hold (e.g. in case of a media re-negotiation or call hold).
Media is placed on hold as specified in RFC 3264 [12]. Media modified to become inactive (SDP direction attribute) shall also be considered to be put on hold.
If a bidirectional media component is placed on hold by making it unidirectional, the IP flows shall only be disabled in the deactivated direction. If a media component is placed on hold by making it inactive, the IP flows shall be disabled in both directions.
Figure B.3.3.1 presents the “Disabling of IP Flows” procedure at media on hold for both the Mobile Originating (MO) side and the Mobile Terminating (MT) side.
Figure B.3.3.1: Disabling of IP Flows at Media on Hold
1. The P-CSCF receives an SDP answer putting media on hold within a SIP message. (NOTE)
2. The P-CSCF sends a Diameter AAR request to the PCRF, requesting that gates shall be closed.
3. The PCRF updates flow status of affected PCC rules for the media on hold.
4. The PCRF sends a Diameter AAA message back to the P-CSCF.
5. The P-CSCF forwards the SDP answer putting media on hold within a SIP message.
6. The PCRF executes interactions according to figure 4.3.1.1.1. This step implies closing the relevant media IP flow gate(s), leaving the possible related RTCP gate(s) open to keep the connection alive.
NOTE: This procedure occurs whenever a bidirectional media is made unidirectional or when a media is changed to inactive.
B.3.4 Media Component Removal
Figure B.3.4.1 presents the flows of PCC procedures at the removal of media component(s) from an IMS session which is not being released for both the Mobile Originating (MO) side and the Mobile Terminating (MT) side.
Figure B.3.4.1: Revoke authorization for IP resources at media component removal
for both Mobile Originating (MO) and Mobile Terminating (MT) side
1. A SIP message containing SDP indicating the removal of media component(s) is received by the P-CSCF.
2. The P-CSCF sends Diameter AAR to the PCRF with modified service information.
3. The PCRF stores the Session information and identifies the affected IP-CAN Session(s).
4. The PCRF sends a Diameter AAA message back to the P-CSCF.
5. The P-CSCF forwards the SDP answer removing a media component.
6. The PCRF makes a decision on what PCC/QoS rules need to be modified or removed and executes interactions according to figure 4.3.1.1.1.