B.1 Provision of Service Information at P-CSCF

29.5143GPP5G SystemPolicy Authorization ServiceRelease 18Stage 3TS

When the "IMS_SBI" feature is supported, the P-CSCF shall send service information to the PCF upon every SIP message that includes an SDP answer payload for the purpose of authorizing the IP flows and the QoS resources required for a negotiated IMS session, unless the SDP payload only relates to a circuit-switched bearer (i.e. "c=" line set to "PSTN" and an "m=" line set to "PSTN", refer to 3GPP TS 24.292 [29]). The service information shall be derived both from the SDP offer and the SDP answer. This ensures that the PCF receives proper information to perform media authorization for all possible IMS session set-up scenarios, and that the PCF is also capable of handling session modifications. The P-CSCF may include "servInfStatus" attribute set to "FINAL".

Additionally, the P-CSCF may send service information to the PCF when receiving a SIP message that includes an SDP offer payload for the purpose of performing an early bandwidth authorization check, or for enabling pre-authorization for a UE terminated IMS session establishment or modification with UE initiated resource reservation, or for the retrieval of network provided access network information (see clause B.8.2).

The P-CSCF shall send service information to the PCF when receiving a SIP message that includes an SDP offer payload when the IMS session is an MPS session that requires priority treatment. For a UE terminated session the P-CSCF may send the service information derived from the SDP offer when the SDP offer either does not include any preconditions information or includes preconditions information indicating that the local preconditions (i.e. the preconditions related to the remote peer) are already met. In this case, the P-CSCF shall derive the service information only from the SDP offer and shall include "servInfStatus" attribute set to "PRELIMINARY".

NOTE 1: For a UE terminated session setup, when the SDP offer either does not include any preconditions information or includes preconditions information indicating that the local preconditions (i.e. the preconditions related to the remote peer) are already met, the terminating UE can request a resource modification prior to sending the SDP answer. Even if the IP address and port information in the session information derived from the SDP offer can be insufficient for PCC rule authorization, the policy to handle such UE initiated requests at the PCF can take into account the fact that an IMS session establishment is ongoing, for instance in deciding whether to authorize the request and in selecting an appropriate charging key and a gating policy.

The P-CSCF shall derive the value of the "fDescs" attribute within the service information from the SDP as follows:

– An uplink entry in the "fDescs" attribute shall be formed as follows: The destination address shall be taken from the SDP information received 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) Source and destination ports shall be derived according to rules provided in 3GPP TS 29.513 [7] clause 7.2.

EXAMPLE 1: Assuming UE A sends an SDP to UE B, the PCF of UE B uses the address present in this SDP for the destination address of UE B’s uplink entry in the "fDescs" attribute, while the PCF of the UE A uses the 64 bit prefix of the same address for the source address of UE A’s uplink entry in the "fDescs" attribute. If the source address is not formed from the 64 bit prefix, the source address shall be wildcarded.

– A downlink entry in the "fDescs" attribute shall be formed as follows: The destination address shall be taken from the SDP information received by the P-CSCF in uplink direction, while the source IP address may be formed (in order to reduce the possibilities of QoS flow misuse) from the destination address in the SDP received by the P-CSCF in downlink direction (taking into account only the 64 bit prefix of the Ipv6 address) Source and destination ports shall be derived according to rules provided in 3GPP TS 29.513 [7] clause 7.2.

EXAMPLE 2: Assuming UE A sends an SDP to UE B, the PCF of UE A uses the address present in this SDP for the destination address of UE A’s downlink entry in the "fDescs" attribute, while the PCF of UE B uses the 64 bit prefix of the same address for the source address of UE B’s downlink entry in the "fDescs" attribute. 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 and "a=bw-info" SDP parameter, if available. If "a=bw-info" is used for bandwidth derivation, the P-CSCF shall use the SDP attribute line that contains the bandwidth properties for the IP version used by the UE, as detailed in 3GPP TS 29.513 [7] clause 7.2. If the received "a=bw-info" SDP attribute line(s) contain only bandwidth properties for an IP version that is not used by the UE, the P-CSCF shall re-compute the bandwidth properties for the used IP version and use that value for the bandwidth derivation as defined in 3GPP TS 26.114 [30].

NOTE 2: If no IP version is included for any of the "a=bw-info" SDP attribute lines related to a certain payload type and direction then IPv6 is assumed for all bandwidth properties related to the same direction and payload type, on all of the related "a=bw-info" SDP attribute lines, see clause 19 of 3GPP TS 26.114 [30].

If "a=bw-info" is used for bandwidth derivation and it includes both known and unknown bandwidth properties, the P-CSCF shall only consider the known bandwidth properties to derive the bandwidth information and ignore the unknown ones. If the" a=bw-info" line is received with an unknown directionality, then the entire "a=bw-info" line shall be ignored.

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.513 [7] clause 7.2. 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.

For multiplexed RTP/RTCP flows (as negotiated using the "a=rtcp-mux" SDP attribute defined in IETF RFC 5761 [31], a P-CSCF supporting RTP/RTCP transport multiplexing shall derive the bandwidth information within the service information as specified in 3GPP TS 29.513 [7] clause 7.2.

However, if service information is received containing the "b=TIAS" SDP parameter that corresponds to an SDP answer payload, and if the P-CSCF supports this parameter, the P-CSCF may derive the bandwidth from this parameter rather than from the "b=AS" SDP parameter, as detailed in 3GPP TS 29.513 [7] clause 7.2.

When available, the P-CSCF shall also indicate to PCF, as a complement to the Service Information, the IMS Communication Service Identifier within the "afAppId" attribute. The originating P-CSCF shall take the IMS Communication Service Identifier value from the SIP response. The terminating P-CSCF shall take the IMS Communication Service Identifier value from the SIP request. Otherwise, the P-CSCF may not be able to provide an IMS Communication Service Identifier value to the PCF. The format and specific headers where IMS communication service identifiers are transported within SIP are defined in 3GPP TS 24.229 [32].

NOTE 3: In order to indicate the IMS Communication Service Identifier to the PCF, the originating P-CSCF sets the "afAppId" attribute to the ICSI contained in the topmost occurrence of the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field(s) of 18x or 2xx SIP response (Feature-Caps: *;+g.3gpp.icsi-ref="urn%Aurn-7%A3gpp-service.ims.icsi.mmtel") and the terminating P-CSCF sets the "afAppId" attribute to the ICSI of the P-Asserted-Service header information received in the SIP request (e.g. P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel). Since the headers and the format of the ICSI can vary depending on the case, the PCF has to be prepared to accept the complete ICSI information received in different formats, as described in clause 7.2A.8.2 in 3GPP TS 24.229 [32].

Additionally, if "ResourceSharing" feature is supported, the P-CSCF may include the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute within a media component of the "medComponents" attribute in order to indicate the PCF that resource sharing should apply for the media components in the related direction with the same value for the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute.

Additionally, if "PrioritySharing" feature is supported, the P-CSCF may provide the "prioSharingInd" attribute within a media component of the "medComponents" attribute as described in clause 4.2.2.21 and 4.2.3.21.

NOTE 4: The P-CSCF obtains this information from the Application Server as described in 3GPP TS 23.228 [33], clause 5.4.7.9.

NOTE 5: RTCP flows are not subject to resource sharing. This requirement cannot be met for multiplexed RTP/RTCP flows as in this case there is no mechanism in the current release to distinguish between RTP and RTCP flows.

For IMS emergency services provided by a PLMN or an SNPN if the "servUrn" attribute does not include an emergency service URN, i.e. a top-level service type of "sos" as specified in IETF RFC 5031 [34] and possibly additional sub-service information on the type of the emergency service and the PCF binds the IMS service session to a PDU session established to an Emergency DNN, the PCF shall return the application error UNAUTHORIZED_NON_EMERGENCY_SESSION to the P-CSCF. Upon receiving an application error UNAUTHORIZED_NON_EMERGENCY_SESSION the P-CSCF shall apply the procedures defined in 3GPP TS 24.229 [32].

NOTE 6: The PCF determines whether a PDU session is established to an Emergency DNN based on the information received over N7 and operator configuration.

If the "afReqData" attribute is provided in the "ascReqData" attribute indicating "5GS-level UE Identities required", the PCF shall provide the available user information for the PDU session in the serving network (either a PLMN or an SNPN) within the "ueIds" attribute included in the "ascRespData" attribute, where each entry shall contain the IMSI (for PLMN access) or either IMSI or NAI (for SNPN access) within the "supi", and/or the MSISDN within the "gpsi" and/or the IMEI(SV) within the "pei" attributes.

The PCF may decide not to authorize requested service information. The PCF will indicate it to the P-CSCF by rejecting the HTTP request with an HTTP "403 Forbidden" response message including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED". Upon receiving an HTTP "403 Forbidden" response message including the "cause" attribute set to the value "REQUESTED_SERVICE_NOT_AUTHORIZED" the P-CSCF shall apply the procedures defined in 3GPP TS 24.229 [32].