The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IPSP flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
Rx interface is used for exchanging application level session information between the Policy and Charging Rules Function (PCRF) and the Application Function (AF). In VoLTE architecture, PCRF is a functional element that determines on how a service data flow will be treated in the enforcement function. This also helps to ensure that the user plane traffic mapping and treatment is in accordance with the user’s profile.
PCRF might use the subscription information as basis for the policy and charging control decisions. The subscription information might be applicable to both sessions based and non-session based services. If AF requests for notification of events, PCRF reports IP-CAN session events (including bearer events and events on AF signaling transport) to the AF through the Rx reference point.
The SBC is enhanced to include the following implementations for Rx interface:
- IP CAN Type Change
- Signaling Bearer Subscription
- Provisioning of Signaling Flows
- Reporting Capabilities to PCRF
- Reporting ICSI Identifier
- Access Network Charging Information
- Access Network Information
- Handling Bearer Path
- SBC Support for Video and MSRP Requirements
For best practices, see Configuring Rx Interface.
IP-CAN Type Change
An IP-CAN type indicates the type of Connectivity Access Network (CAN) in which a user is connected. The association between UE and IP network is called IP-CAN session. This association is identified by UE's IP4 address and/or IP6 prefix with a UE identity information. An IP-CAN session incorporates one or more IP-CAN bearers. IP-CAN session exists as long as the related UE IPv4 address and/or IPv6 prefix are assigned to the IP network.
When the SBC receives an initial REGISTER SIP message from an attached UE, it requests from PCRF the initial SIP REGISTER information about the type of IP-CAN attached to the UE. The SBC also subscribes to notifications for changes of the IP-CAN type used by the UE within the same AAR command. The SBC includes a "Specific-Action" AVP in the AAR that is set to the value of "IP-CAN_CHANGE".
Call flow description
- User initiates an initial SIP Registration procedure.
- SBC requests the establishment of a new Diameter Rx session with the intention to subscribe to the notification of IP-CAN Type change.
- SBC sends a Diameter AAR command to the PCRF. PCRF performs session binding and identifies corresponding PCC rules related to IMS Signaling.
- PCRF confirms the subscription to notification of change of IP-CAN type and replies with a Diameter AAR command back to the SBC. PCRF responds the type of IP-CAN currently used.
The SBC stores the IP-CAN information after receiving the AA Answer or or RA-Request from the PCRF. During an IP-CAN session modification, this AVP is also present when there has been a change in the IP-CAN type and the PCRF is requested to notify this event. When the SBC receives a notification of the change of the IP-CAN used by the UE, The SBC stores the new IP-CAN type information. The SIP registration procedure is completed successfully.
When the SBC receives an initial REGISTER SIP message from an attached UE, it subscribes to the status of the AF Signaling transmission path. The SBC cancels the subscription notification of the status of AF signaling transmission path when AF signaling to that particular user is terminated (When the user is de-registered).
The user initiates an initial SIP registration procedure successfully. The SBC establishes new Rx session to subscribe to the status of the IMS Signaling path and sends AAR command to PCRF with the Specific-Action AVP requesting the subscription to "INDICATION_OF_LOSS_OF_BEARER". PCRF performs session binding and identifies corresponding PCC Rules related to IMS Signaling. PCRF confirms the subscription to IMS Signaling path status and replies with a Diameter AAR command back to the SBC.
If PCRF is notified the loss or release of resources associated to the PCC/QoS rules corresponding with AF Signaling IP flows, informs the SBC about the loss of the signaling transmission path by sending a re‑authorization request (RAR) command with specific-action AVP set to "INDICATION_OF_LOSS_OF_BEARER” or “INDICATION_OF_RELEASE_OF_BEARER" and the deactivated IP Flow encoded in the flows AVP. When the SBC receives RAR command, it acknowledges the command by sending an RAA command to PCRF.
Provisioning of Signaling Flows
For sending the provisioned AF signaling IP flows between the UE and AF, the AF uses an Rx Diameter session, which is already opened with the PCRF (that is, if an Rx Diameter session related to AF signaling is already established). AF modifies the already opened Rx Diameter related to the AF signaling (for example, an Rx Diameter session established for the purpose of subscription to notification of signaling path) or it tries to re-open a new Rx Diameter session related to the AF signaling if none exists. When the PCRF receives from the AF an AA-Request, the PCRF performs session binding and acknowledges the AAR command by sending an AA‑Answer command to the AF.
For sending the de-provisioned AF signaling IP flows at any time, the Rx Diameter session is used for providing information on the AF signaling IP flows. The AF closes the Rx Diameter session by sending a Session-Termination-Request (STR) command to the PCRF, which is acknowledged with a Session-Termination-Answer (STA) command.
Reporting Capabilities to PCRF
The SBC sends the supported-Features AVP during session establishment, to inform the destination host about the required and optional features supported by the origin host. The SBC indicates the set of supported features in the first request of a Diameter session. The server then responds with the set of features that it has in common with the client and the server supports within the same Diameter session in the first answer.
The PCRF is capable of handling the following functionality :
- If the AF supporting Rx functionality inter-operates with a PCRF supporting feature, the AAR includes the features supported by the AF within supported-features AVP(s) with the "M" bit cleared. Otherwise, the AAR includes the supported features within the supported-features AVP(s) with the M-bit set.
- If the AAR command does not contain any supported-features AVP(s) and the PCRF supports Rx functionality, the AAA command does not include the supported-features AVP. In this case, both AF and PCRF will behave as specified feature.
- If the AAR command contains the supported-features AVP(s), the PCRF includes the supported-features AVP(s) in the AAA command with the ‘M’ bit cleared, indicating only the features that both the PCRF and AF support.
Report ICSI Identifier
The AF-Application-identifier AVP contains information that identifies the particular service that the AF service session belongs to. This information is used by the PCRF to differentiate QoS for different application services. AF-Application-Identifier is used as additional information together with the Media-Type AVP when the QoS class for the bearer authorization at the Gx interface is selected.
The AF-Application-Identifier is also used for completing the QoS authorization with application specific default settings in the PCRF and if the AF does not provide full Session-Component-Description information.
The SBC includes the AF-Application-Identifier AVP into the AA-Request. This AVP is provided at both, session level and Media-component-description level. When provided at both levels, the AF-Application Identifier provided within the Media-Component-Description AVP takes priority. The SBC indicates to PCRF as a complement to the service information the IMS communication service identifier within the AF-Application-Identifier AVP.
Access Network Charging Information
The SBC includes the access-network-charging-info parameter received through PCRF over the Rx or Gx interfaces in the P-charging-vector header field. The charging information is available in the SBC after the local resource reservation is completed.
The SBC receives an INVITE request, includes the access-network-charging-info parameter in the P-Charging-Vector header field. This request is originated by the UE that traverses the SBC as soon as the charging information is available, for example, after the local resource reservation is completed.
This request acts as an UPDATE request if the remote UA supports the "integration of resource management in SIP" extension or a Re-INVITE request if the remote UA does not support the "integration of resource management in SIP" extension.
The call flow depicts the same information:
The SBC subscribes to PCRF to provide the access network charging identifier to the AF for each authorized flow, when the access network charging identifier becomes known at the PCRF. To achieve this subscription, the SBC sends AAR, with Specific-Action AVP containing CHARGING_CORRELATION_EXCHANGE. The AF may include the AF-Charging-Identifier AVP into the AA-Request for charging correlation purposes. The AF-Charging-Identifier is filled with ICID value from the P-Charging-Vector.
If the SBC subscribes to a notification of Access Network Charging Information, the PCRF provides the Access Network Charging Information as mentioned in the following way:
PCRF sends a Re-Authorization-Request (RAR) command when the Access Network Charging Information is received from the PCRF. If different Access Network Charging Information is applicable to the IP-CAN session, the PCRF notifies the AF about the Access Network Charging Information that applies to each authorized flow. The RAR includes the Specific-Action AVP set to the value "CHARGING_CORRELATION_EXCHANGE" and includes the assigned Access‑Network-Charging-Identifier(s) and tries to include the Access-Network-Charging-Address AVP.
Access Network Information
When the SBC receives any request or response from the UE, the SBC inserts a P-Access-Network-Info header field.
The SBC requests the PCRF to report the access network information (user location, user timezone), the SBC subscribes to the “ACCESS_NETWORK_INFO_REPORT" within the Specific-Action AVP and includes the required access network information within the Required-Access-Info AVP. The SBC requests PCRF to report the access network information in conjunction with providing PCRF with AF session information. The SBC also requests PCRF to report the access network information at Rx session termination. To do so, it needs to include the required access network information within the Required-Access-Info AVP in the corresponding ST-Request. PCRF does not report any subsequently received access network information to AF, unless AF sends a new request for access network information.
When PCRF receives a request to report the access network information from the SBC, it immediately configures PCEF or BBERF to provide such access network information. When PCRF receives the requested access network information from PCEF/BBERF, it provides the corresponding access network information to AF within 3GPP-User-Location-Info AVP (if available), User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP. If PCRF receives the serving PLMN identifier from PCEF/BBERF instead of the requested access network information, PCRF provides the serving PLMN identifier within 3GPP-SGSN-MCC-MNC AVP to AF. When PCRF receives a request to report the access network information from AF in an AAR command or in STR command triggered by AF, if PCRF determines that the access network does not support the access network information reporting based on the currently used IP-CAN type or the values of RAT-Type AVP and AN-Trusted AVP or PCEF/BBERF does not support the access network information reporting based on the Supported-Feature AVP, PCRF responds to AF with an AAA or STA command including NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED).
Retrieving Location Information
The call flow depicts the same information
Call flow description
If the originating SBC is required by operator policy to retrieve network provided location information before forwarding a SIP INVITE request, upon reception of an INVITE/UPDATE request, the SBC sends an AA-Request with the "ACCESS_NETWORK_INFO_REPORT" value within the Specific-Action AVP and the required access network information within the Required-Access-Info AVP.
On receiving Initial INVITE from UE, the SBC sends AAR (Initial) with the specific-action AVP containing value “ACCESS_NETWORK_INFO_REPORT” and Required-Access-Info AVP set to USER_LOCATION and MS_TIME_ZONE. This is sent if the configuration value “fetchLocationInfo” is set to retrieveInOffer. On receiving Initial INVITE without SDP from UE, the SBC sends AAR on receiving SIP Response with offer. On receiving RAR with specific action ACCESS_NETWORK_INFO_REPORT, SBC stores the 3GPP-User-Location-Info AVP, User-Location-Info-Time AVP, 3GPP-SGSN-MCC-MNC AVP and/or 3GPP-MS-TimeZone AVP if available. On receiving AAA from PCRF, SBC checks NetLoc-Access-Support set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED).
If so, the SBC continues with the call irrespective of the flag fetchLocationInfo . If an originating SBC is required by operator policy to retrieve network provided location information before forwarding an SDP answer, the SBC upon reception of an SDP offer sends an AA-Request to the PCRF with "ACCESS_NETWORK_INFO_REPORT" value within the Specific-Action AVP and the required access network information within the Required-Access-Info AVP. Upon reception of an SDP answer, the P-CSCF sends an AA-Request to the PCRF. If the SBC does not request an access network information on reception of the SDP offer, the SBC includes in this AA-request, the “ACCESS_NETWORK_INFO_REPORT” value within the Specific-Action AVP; and the required access network information within the Required-Access-Info AVP.
The table describes the the SBC behavior:
|Received PANI header?|
Insert P-Access Network Info
|PANI transparency flag||Validate PANI||P-CSCF Behavior|
|Yes/No||Enable||Enabled/disabled||Enabled/disabled||Constructs and Sends PANI with received location info(Ignores If it received at ingress side)|
Handling Bearer Path
This conveys on how to handle the loss of bearer events in RAR messages. When a loss of bearer of stream is lost, PCRF informs about loss of bearer events INDICATION_OF_LOSS_OF_BEARER/ INDICATION_OF_FAILED_RESOURCES_ALLOCATION in RAR message.
In VOLTE, UE performs the call establishment in core IMS network. The IMS signaling is sent over the default bearer and a new dedicated bearer is dynamically established for the voice traffic.
If bearer for voice is lost mid-session, PCRF informs the SBC about loss of bearer by sending RAR and the SBC terminates the session by sending BYE. If bearer for other streams is lost , the PCRF informs the SBC about loss of bearer; the SBC, based on local policy, can continue with the call with audio if present (or) terminate the call.
The call flow below depicts the same information:
Rx Requirements for SBC between UE and P-CSCF
When the SBC is placed between UE and P-CSCF, P-CSCF only has access to the SBC egress IP address and port. It doesn’t have access to UE’s IP address as well as the SBC ingress IP address. P-CSCF cannot pass the right IP address (es) to PCRF and PCRF cannot configure QoS over air interface. Hence SBX should pass UE’s IP address as well as the SBC ingress IP address in a proprietary extension (SIP header or SDP parameter) to P-CSCF.
For SIP messages heading to P-CSCF from the SBC, the contained SDP information should be delivered to P-CSCF using ‘UE-Flow-Info-Param’. (This rule applies to session update procedure as well as session setup procedure. The information encompasses IP addresses and ports attached to:
- SBC-Core and SBC-Access IPAdress
- Endpoint IP-Address respectively.
The syntax of the proprietary header P-UE-Flow-Info is as follows:
The call flow below depicts the same information.
When the flag
insertUEFlowInfo is enabled at the core side, the SBC inserts "P-UE-Flow-Info" header for all the SIP requests/response messages along with SDP.
SBC Support For Video and MSRP Requirements
The SBC also supports the video call requirements. The media component description AVP supports the media-type AVP with value as "1", so as to handle the video call. The SBC also supports MSRP protocol , for transmitting a series of related instant messages in the context of a communications session. It sends the AAR with Media-Type AVP as "DATA" to establish a MSRP session.
The bandwidth for MSRP/BFCP is mentioned only if the SDP is received from the UE and sent to the network. The SBC sends the Max-Requested-Bandwidth-DL which is set to 10k for IM and 100 Kbytes for File Transfer.
The following are list of the AVPs present on the Rx interface with the below mentioned fields.
|Required Access Info||Enumerated||536|
This field contains the access network information required for that AF session.The following values are defined:
This field indicates whether AVP is present and informs the destination host about the features that the origin host supports. The Feature-List AVP contains a list of supported features of the origin host. The Vendor-ID AVP and the Feature-List AVP together identifies which feature list is carried in the Supported-Features AVP
AVP format :
|IP CAN Type||Enumerated||1027|
This field indicates the type of Connectivity Access Network in which the user is connected.
The following values are defined:
This field is used to identify the radio access technology that is serving the UE. The following values are defined:
|NetLoc-Access-Support||Enumerated||2824||This field indicates whether PCRF support location info or not.|
|GPP-User-Location-Info||Octet String||22||This field indicates details of where the UE is currently located.|
|3GPP-User-Location-Info-Time||Time||2812||This field indicates the time the UE was last known to be in the location which is reported during bearer deactivation or UE detach procedure.|
This field indicates the GPRS, the MCC, and the MNC for the SGSN. And in case of 3GPP this indicates the EPS, the MCC, and the MNC as provided by the serving gateway (SGW).