5 Policy control procedures

29.2093GPPPolicy control over Gq interfaceRelease 6TS

5.1 PDF

5.1.1 Initial authorization of QoS resources

When receiving an initial AA-Request from the AF, the PDF allocates Authorization-Token. The PDF shall store the Diameter base protocol Session-Id received in the AA-Request message for the Authorization-Token. If the AA‑Request contains the Media-Component-Description Attribute-Value Pair(s) (AVP(s)) the PDF shall authorize the required QoS resources and store the SBLP for the session based on the service information. If the AA-Request contains Flow-Grouping AVP(s), the PDF shall only authorize the QoS if the IP flows are distributed to PDP contexts in a way that is allowed by the Flow-Grouping AVP(s). The PDF sends the allocated token in the Authorization-Token AVP to the AF in the AA-Answer message.

5.1.2 Resource reservation

When receiving a bearer authorization request from the Go interface, the PDF shall authorize the request according to the stored SBLP for the session, if available.

For a bearer authorization request with a new authorization token the PDF shall behave as described within the present paragraph: If the SBLP is not available for the session, or if the AF has instructed the PDF to do so, the PDF shall send the Re-Auth_Request message with the SERVICE_INFORMATION_REQUEST indication in the Specific-Action AVP to the AF to request the service information. When receiving the Media-Component-Description AVP(s) in the Re-Auth-Answer message, the PDF shall authorize the required QoS resources and shall store the SBLP for the session. If SBLP is available for the session butauthorization for unknown flow identifiers is being requested, and the AF has not instructed the PDF to contact it at bearer authorization, the PDF shall deny the authorization without contacting the AF.

For a bearer authorization request for an authorization token already authorized by the PDF, the PDF shall behave as described within the present paragraph: If the request contains binding information for media with no corresponding SBLP available at the PDF, or if the PDF has already authorized the same binding information and not obtained updated service information since then, or if the AF has instructed the PDF to do so, the PDF shall send a Re-Auth-Request message with the SERVICE_INFORMATION_REQUEST indication in the Specific-Action AVP to the AF to request updated service information. When receiving the Media-Component-Description AVP(s) in the Re‑Auth‑Answer message the PDF shall authorize the required QoS resources and shall store the SBLP for the session.

After the bearer authorization the PDF shall send possible new access network charging identifier(s) (e.g. GCID), received from the GGSN during the bearer authorization to the AF for charging correlation purposes, and an access network charging-address (e.g. GGSN IP Address), if the AF has instructed the PDF to do so. The PDF does this by sending the Re-Auth_Request message with the CHARGING_CORRELATION_EXCHANGE indication in the Specific-Action AVP to the AF. The access network charging identifier(s) and the access network charging-address should not be sent over an inter-operator interface.

5.1.3 Gate function

The AF shall indicate to the PDF as part of the Media-Component-Description AVP(s) whether the media IP flow(s) should be enabled or disabled at the bearer authorization. The PDF may receive a separate AA-Request message(s) from the AF to enable or disable specified IP flows. The PDF shall reply with an AA-Answer and shall include the Access‑Network-Charging-Identifier(s) available at this moment. The PDF makes the final decision to enable or disable the authorized IP flows.

5.1.4 Session modification

The PDF may receive the AA-Request message from the AF with modified service information. The PDF shall store the SBLP for the session based on the new service information. The PDF shall acknowledge the session modification by issuing an AA-Answer back to the AF and shall include the Access-Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address, if they are available at this moment and have not yet been supplied earlier to the AF. The PDF shall enforce corresponding bearer modifications as detailed in 3GPP TS 29.207 [4].

5.1.5 Bearer modification

The bearer authorization for the session- or bearer-initiated modification is performed as specified in 3GPP TS 29.207 [4].

If the AF has requested a notification at the loss of a bearer, and the PDF receives a notification that a PDP context is modified to the bandwidth of 0 kbit via the Go interface, the PDF shall send a Re-Auth_Request with the value for the Specific-Action AVP set to INDICATION_OF_LOSS_OF_BEARER and shall indicate the affected IP flows with the Flows AVP(s) if not all IP flows within an AF session are affected.

If the AF has requested a notification at the recovery of a bearer, and the PDF receives a notification that a PDP context is modified from the bandwidth of 0 kbit to a higher value via the Go interface, the PDF shall send a Re-Auth_Request with the value for the Specific-Action AVP set to INDICATION_OF_RECOVERY_OF_BEARER and shall indicate the affected IP flows with the Flows AVP(s) if not all IP flows within an AF session are affected.

5.1.6 Revoke authorization

When receiving the Session-Termination-Request message from the AF, the PDF shall revoke the bearer authorization as detailed in 3GPP TS 29.207 [4]. The PDF should free any internal resources it allocated for the corresponding Diameter Gq session and may reuse the authorization token allocated to the corresponding AF session after answering with a Session-Termination-Answer message to the AF.

5.1.7 Indication of bearer release

If the AF has requested a notification at the release of a bearer, and the PDF receives a notification that a PDP context is released via the Go interface, but not all IP flows within the corresponding AF session are affected by the PDP context release, the PDF shall send a Re-Auth_Request with the value for the Specific-Action AVP set to INDICATION_OF_RELEASE_OF_BEARER and shall indicate the affected IP flows with the Flows AVP(s) and the appropriate Abort-Cause AVP value.

When the GGSN informs the PDF of the PDP context release and all IP flows within the corresponding AF session are affected, the PDF shall inform the AF about this event by sending the Abort-Session-Request message with the appropriate Abort-Cause AVP value.

5.2 AF

5.2.1 Initial authorization of QoS resources

When receiving an AF session signalling message initiating a new AF session, the AF shall request an authorization for the session from the PDF by sending the AA-Request message. The AF shall include the corresponding Media‑Component-Description AVP(s) into the message if the SDI is already available at the AF. The AF may include the Flow-Grouping AVP(s) to request a particular way on how the IP flows described within the service description are distributed to PDP contexts. The AF may also include the AF-Charging-Identifier AVP into the message for the charging correlation purposes.

The AF receives the Authorization-Token AVP from the PDF in the AA-Answer message. The usage of Authorization-Token is application dependent.

The behaviour when the AF does not receive the AAA, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.

5.2.2 Resource reservation

The PDF may contact the AF at the UE resource reservation by sending the Re-Auth-Request message with a request for the service information. The AF shall respond with the Re-Auth-Answer message containing the Media-Component-Description AVP(s). The information in the Media-Component-Description AVP(s) may be based on the session description information negotiated within the AF session signalling. The AF does not need to send a new authorization request back to the PDF when receiving a Re-Auth-Request message with a request for the service information. The AF may include the Flow-Grouping AVP(s) to request a particular way on how the IP flows described within the service description are distributed to PDP contexts.

The AF may receive an access network charging identifier (e.g. GCID) and access network charging address (e.g. GGSN IP address) for charging correlation purposes from the PDF in a separate Re-Auth-Request message after the bearer has been authorized. The AF does not need to send a new authorization request when receiving a Re-Auth-Request message with access network charging identifier (e.g. GCID) and access network charging address (e.g. GGSN IP address).

5.2.3 Gate function

The AF shall indicate to the PDF as part of the Media-Component-Description whether the media IP flow(s) should be enabled or disabled at the bearer authorization. Depending on the application, the AF may instruct the PDF also during the session when the IP flow(s) are to be enabled or disabled to pass through the access network. The AF does this by sending the AA-Request message containing the Media-Component- Description AVP(s) that contains the flow status information for the flows to be enabled or disabled.

The behaviour when the AF does not receive the AAA, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.

5.2.4 Session modification

During the AF session modification, the AF shall send an update for the session description information to the PDF based on the new SDI exchanged within the AF session signalling. The AF does this by sending the AA-Request message containing the Media-Component-Description AVP(s) containing the updated service information. The AF may include the Flow-Grouping AVP(s) to request a particular way on how the IP flows described within the service description are distributed to PDP contexts.

The behaviour when the AF does not receive the AAA, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.

5.2.5 Revoke authorization

When AF session is terminated the AF shall revoke the corresponding bearer authorization by the sending Session‑Termination-Request message to the PDF.

5.3 IMS related P-CSCF procedures

5.3.1 Provisioning of Service Information at P-CSCF

The P-CSCF shall send service information to the PDF upon every SIP message that includes an SDP answer payload. The service information shall be derived both from the SDP offer and the SDP answer. This ensures that the PDF receives proper information to perform media authorization for all possible IMS session set-up scenarios, and that the PDF is also capable of handling session modifications.

All media components in the SDP shall be authorized. Therefore, the P-CSCF shall derive a media component within the session information from every SDP media component, as detailed in 3GPP TS 29.208 [5]. The SDP contains sufficient information about the session, such as the end-points’ IP address and port numbers and bandwidth requirements.

The P-CSCF shall derive Flow-Description AVP within the service information from the SDP as follows:

– An uplink Flow-Description AVP shall be formed as follows: The destination address and port number shall be taken from the connection information parameter of the SDP sent by the P-CSCF in downlink direction, while the source IP address may be formed from the address present in the SDP received by the P-CSCF in uplink direction (taking into account only the 64 bit prefix of the IPv6 address), and the source port number shall be wildcarded. For example, assuming UE A sends an SDP to UE B, the PDF of UE B uses the address present in this SDP for the destination address of UE B’s uplink Flow-Description AVP, while the PDF of the UE A uses the 64 bit prefix of the same address for the source address of UE A’s uplink Flow-Description AVP. If the source address is not formed from the 64 bit prefix, the source address shall be wildcarded.

– An downlink Flow-Description AVP shall be formed as follows: The destination address and port number shall be taken from the connection information parameter of the SDP received by the P-CSCF in uplink direction, while the source IP address may be formed (in order to reduce the possibilities of bearer misuse) from the destination address in the SDP sent by the P-CSCF in downlink direction (taking into account only the 64 bit prefix of the IPv6 address) and the source port number shall be wildcarded. For example, assuming UE A sends an SDP to UE B, the PDF of UE a uses the address present in this SDP for the destination address of UE A’s downlink Flow-Description AVP, while the PDF of UE B uses the 64 bit prefix of the same address for the source address of UE B’s downlink Flow-Description AVP. If the source address is not formed from the 64 bit prefix, the source address shall be wildcarded.

The P-CSCF shall derive the bandwidth information within the service information, from the "b=AS" SDP parameter, as detailed in 3GPP TS 29.208 [5]. For the possibly associated RTCP IP flows, the P-CSCF shall use the SDP "b=RR" and "b=RS" parameters, if present, as specified in 3GPP TS 29.208 [5]. The "b=AS", "b=RR" and "b=RS" parameters in the SDP contain all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTCP payload, or IP, UDP and RTCP.

5.3.2 Enabling of IP Flows at P-CSCF

Prior to the completion of the SIP session set-up, i.e. until the 200 OK(INVITE) is received, the P-CSCF may enable or disable media IP flows depending on operator policy, thus allowing of forbidding early media in forward and/or backward direction. Only to disable early media, the P-CSCF may modify the values of the Flow-Status AVPs derived from SDP according to 3GPP TS 29.208 [5]. If the P-CSCF chooses to modify the values, the P-CSCF shall store the last received SDP.

When the 200 OK is received, the P-CSCF shall enable all media IP flows according to the direction attribute within the last received SDP, as specified in 3GPP TS 29.208 [5]. When the 200 OK is received and the P-CSCF previously provided modified values of the Flow-Status AVPs in the session information, the P-CSCF shall provide service information with values of the Flow-Status AVPs corresponding to the last received SDP.

If the P-CSCF receives SDP answers after the completion of the SIP session set-up, i.e. after the 200 OK(INVITE) is received, the P-CSCF shall provide the Flow-Status AVPs as derived from the SDP according to 3GPP TS 29.208 [5].