The Representational State Transfer (REST) reference point resides between the AF and the Protocol Converter (PC). The PC converts application level information received from the AF to Diameter session information and communicates with the PCRF via the Diameter based Rx reference point (TS 29.214).
The Rx reference point, which is based on Diameter, is defined between the PCRF and the AF in TS 29.214. If the AF supports RESTful HTTP and XML a Protocol Converter (PC) is needed. In this specification the interface between the AF and the PC is named REST-Rx. The REST-Rx interface shall be used in non-IMS scenarios only.
The PC converts the information, received over the REST-Rx interface, into information that can be used on the Diameter based Rx interface in order to get an access to the PCC architecture and vice versa. The PC manages RESTful resources, which are an integral part of the REST-Rx interface. As defined in the stage 2 specifications (TS 23.203), information from the AF is part of the input used by the PCRF for Policy and Charging Control (PCC) decisions. Signalling flows are specified in Annex A.
The overall PCC architecture is depicted in subclause 3a of TS 29.213.
The relationships between the different functional entities involved are depicted in Figure 4.2.1.
The AF is an element offering applications that require the Policy and Charging Control of traffic plane resources (e.g. UMTS PS domain/GPRS domain resources). The AF shall use the Rx reference point to provide session information to the PCRF.
If the AF only supports RESTful HTTP and XML a protocol converter is needed between the AF and the PCRF.
The Protocol converter (PC) is an element converting information carried over RESTful HTTP and XML to information carried over Diameter in order to get an access to the PCC architecture.
When a new AF session is being established and media information for this AF session is available at the AF and the related media require PCC supervision, the AF shall open an RESTful Rx session with the PC for the AF session using an HTTP POST message that addresses the resource responsible for resource creation, unless an Rx session has already been established for the AF session. If the RESTful Rx session already exists for the AF session, the AF uses the existing RESTful Rx session and shall use the HTTP PUT message including the AF Session ID in the path element to address the existing resource. The AF shall provide the full IP address of the UE using either UEIP element or UEIPv6 element, and the corresponding Service Information within MCD group(s). The AF shall not include circuit-switched bearer related media in the service information sent to the PC. The AF shall indicate to the PC as part of the MCD element whether the media IP flow(s) should be enabled or disabled with the FlowStatus element.
The AF may include the AFAppId element into the AF session establishment representation in order to indicate the particular service that the AF session belongs to. This element can be provided at both AF session level, and media component description level. When provided at both levels, the AFAppId element provided within the MCD group will have precedence.
The AF may include the AFChargingId element into the AF session establishment representation for charging correlation purposes. The AF may also include the SpecificAction element to request notification for certain user plane events, e.g. bearer termination.
The AF may include the SvcURN element in order to indicate that the new AF session relates to emergency traffic.
The AF may include the MPSId element in order to indicate that the new AF session relates to an MPS session.
If the AF provides service information that has been fully negotiated, the AF may include the SvcInfoStatus element set to FINAL_SERVICE_INFORMATION as specified in TS 29.214.
The AF may additionally provide preliminary service information not fully negotiated yet at an earlier stage. To do so, the AF shall include the SvcInfoStatus element with the value set to PRELIMINARY SERVICE INFORMATION as specified in TS 29.214.
For sponsored data connectivity and if SponsoredConnectivity is supported, the AF shall provide the application service provider identity and the sponsor identity to the PCRF via the PC by including the ASPId element and the SponsId element in the SpConnData group in the AF session establishment representation. Additionally if SponsorChange is supported the AF shall provide an indication whether to enable or not enable sponsored data connectivity to the PCRF by including the SponsAct element set to the applicable value.
To support the usage monitoring of sponsored data connectivity, the AF may also include the GSU group in the SpConnData group and the SpecificAction element set to the value USAGE_REPORT as specified in TS 29.214 to request notification when the usage threshold has been reached.
If the PCRF includes the Retry-Interval AVP within the AA-Answer command to the PC, the PC shall provide the same value of retry interval in the RetryInterval element in the AF session establishment representation. The AF shall not send the same service information to the PCRF (via the PC) again (for the same IP-CAN session) until the retry interval has elapsed.
To allow the PCRF and PCEF to perform PCC rule authorization and bearer binding for the described service IP flows, the AF may supply both source and destination IP addresses and port numbers within the FlowDesc element, if such information is available.
The AF may specify the TTC element for the described service data flows together with the FlowDesc element.
The AF may specify the ResPrio element at request level in the AF session establishment representation in order to assign a priority to the AF session as well as specify the ResPrio element at the media component description level to assign a priority to the IP flow. The presence of the ResPrio in both levels does not constitute a conflict as they each represent different types of priority. Specifically the ResPrio at the AF session establishment representation level provides the relative priority for a session while the ResPrio at the media component description level provides the relative priority for an IP flow within a session. If the ResPrio element is not specified the requested priority is DEFAULT (0) as specified in TS 29.214.
The AF may request notifications of specific IP-CAN session events through the usage of the SpecificAction element in the AF session establishment representation. The HTTP POST message, which is used to establishment of a new session, shall include the notification URL in the representation.
The AF may include the ReqType element set to INITIAL_REQUEST as specified in TS 29.214.
To allow the PCRF to derive the PCC rules for the background data transfer according to the transfer policy stored in the SPR, the AF may supply the reference id of transfer policy in the RefId element.
When the PC receives the SuppFeatures element from the AF, it shall only include in the corresponding Diameter Supported-Features AVP sent to the PCRF the intersection of the AF advertised features and the features supported by the PC.
The behaviour when the AF does not receive the HTTP 201 CREATED response, or when it arrives after the internal timer waiting for it has expired, is out of scope of this specification and based on operator policy.
The AF may modify the session information at any time (e.g. due to an AF session modification or internal AF trigger) by sending an HTTP PUT message to PC including the AF session ID as an URL address and the MCD group(s) with the updated Service Information in the HTTP body. The AF shall send an AF session modification request representation to the PCRF via the PC, only after the previous AF session modification request has been acknowledged.
If the AF provides service information that has been fully negotiated, the AF may include the SvcInfoStatus element set to FINAL_SERVICE_INFORMATION as specified in TS 29.214.
The AF may additionally provide preliminary service information not fully negotiated yet at an earlier stage. To do so, the AF shall include the SvcInfoStatus element with the value set to PRELIMINARY SERVICE INFORMATION as specified in TS 29.214.
The AF may include the ReqType element set to UPDATE_REQUEST as specified in TS 29.214 in the AF SESSION MODIFICATION REQUEST.
The AF may include the MPSId element in order to indicate that the modified AF session relates to an MPS session.
For sponsored data connectivity and if Sponsored Connectivity is supported, the AF shall provide the application service provider identity and the sponsor identity to the PCRF via the PC by including the ASPId element and the SponsId element in the SpConnData group in the AF session modification representation.
If SponsorChange is supported and the AF requests to enable sponsored data connectivity the AF shall provide the application service provider identity, the sponsor identity and an indication to enable sponsored data connectivity to the PCRF via the PC by including ASPId element, the SponsId element and the SponsAct element set to the value ENABLE_SPONSORING (1) in the SpConnData group in the AF session modification representation.
If the AF requests to disable sponsored data connectivity the AF shall provide an indication to disable sponsored data connectivity to the PCRF via the PC by including the SponsAct element set to the value DISABLE_SPONSORING (0) in the SpConnData group in the AF session modification representation.
To support the usage monitoring of sponsored data connectivity, the AF may also include the GSU group in the SpConnData group in the AF session modification representation.
To allow the PCRF to derive the PCC rules for the background data transfer according to the transfer policy stored in the SPR, the AF may supply the reference id of transfer policy in the RefId element.
If the PCRF includes the Retry-Interval AVP within the AA-Answer command to the PC, the PC shall provide the same value of retry interval in the RetryInterval element in the AF session modification representation. The AF shall not send the same service information to the PCRF (via the PC) again (for the same IP-CAN session) until the retry interval has elapsed.
When an AF session is terminated, the AF shall send an HTTP DELETE message including the AF Session ID as an URL address to the PC.
If the AF requires access network information at this step, the AF shall include the ReqAccInfo element within the AF session termination representation, indicating the required information.
Depending on the application, in the Service Information provision, the AF may instruct the PCRF via the PC by sending an HTTP PUT message when the IP flow(s) are to be enabled or disabled to pass through the IP-CAN. The AF does this by sending the gate status request message representation containing the MCD group(s) that contains the flow status information (in the FlowStatus element) for the flows to be enabled or disabled.
The behaviour when the AF does not receive the gate status response from the PC, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than SUCCESS, are outside the scope of this specification and based on operator policy.
An AF may subscribe to notifications of the status of the AF signalling transmission path. To do so, the AF shall send an HTTP POST message to establish an AF session with the PC (as per sub-clause 5.3.4). The HTTP POST message shall provide a URL which shall be used as a notification URL by the PC. The AF shall provide the UE's IP address (using either the UEIP element or the UEIPv6 element) and the SpecificAction element requesting the subscription to "INDICATION_OF_LOSS_OF BEARER" and/or "INDICATION_OF_RELEASE_OF_BEARER" in the representation. The AF shall additionally provide an MCD group including a single MSC group with the FlowUsage element set to the value "AF_SIGNALLING" within the representation. The MCD group shall contain the MCN element set to "0".
If the AF Session is only used for subscription to Notification of Signalling Path Status, the AF may cancel the subscription to notifications of the status of the AF Signalling transmission path. In that case, the AF shall send an HTTP DELETE message to the PC, which shall be acknowledged with an HTTP 200 OK response.
If the PC receives a Diameter RAR command for traffic plane events reporting as defined in subclause 4.4.6 of TS 29.214, the PC includes the content translated from the RAR command as a representation into an HTTP PUT message to indicate to the AF the traffic plane events. After the PC receives the HTTP 200 OK response from the AF, the PC converts the representation of the response to a Diameter RAA command and sends the Diameter RAA command to the PCRF as specified in TS 29.214.
If the PC receives a Diameter ASR command for IP-CAN session termination as defined in subclause 4.4.6.1 and 4.4.6.2 of TS 29.214, the PC includes the content translated from the ASR command as a representation into an HTTP PUT message to indicate to the AF the IP-CAN session termination. After the PC receives the HTTP response from the AF and the response includes a representation of an ASA, the PC converts the the representation of the response to a Diameter ASA command and sends the Diameter ASA command to the PCRF as specified in TS 29.214. The AF initiates the session termination procedure as defined in subclause 4.5.4.