Rx Interface Support

Overview

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.

Subscription

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

Figure 1: IP CAN Subscription and Notification flow

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.

Notification

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. 

Signaling Bearer

Subscription

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.

Figure 2: Signaling Status Call Flow

Notification

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:

 Figure 3: Originating Call Access Network

Subscription

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.

Notification

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.

Subscription

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.

Notification

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:

Figure 4: Originating Call for PCSCF

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:

Table 1: SBC Behavior

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.

Subscription

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.

Notification

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:

Figure 5: Handling Bearer Path

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:

P-UE-Flow-Info ="P-UE-Flow-Info" HCOLON UE-Flow-Info-Param *(COMMA UE-Flow-Info-Param)
UE-Flow-Info-Param =type SEMI
"src" EQUAL LDQUOT ip_address HCOLON port RDQUOT SEMI
"msrc" EQUAL LDQUOT ip_address HCOLON port RDQUOT SEMI
"dst" EQUAL LDQUOT ip_address HCOLON port RDQUOT
type     =    "sig" / "video" / "audio" / "message" / "data" / "application" /"text" / "control"
 / "other"
ip_address =    IPv4address / IPv6reference
IPv4address =     1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address =     hexpart [ ":" IPv4address ]
Port =         1*DIGIT

The call flow below depicts the same information.

Figure 6: P-UE-Flow-Info

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.

AVP

The following are list of the AVPs present on the Rx interface with the below mentioned fields.

Table 2: AVP List