Versions Compared

Old Version 3

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version 4

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

width24px
Noprint
Panel
borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

Back to Managing Billing Records

...

Panel

In this section:

Table of Contents
maxLevel3

...

...

width40%
Info
iconfalse

Related articles:

...

...

 

Overview

Div
classexcerptdiv
Excerpt

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:

  1. IP CAN Type Change
    1. Subscription
    2. Notification
  2. Signaling Bearer Subscription
    1. Subscription
    2. Notification
  3. Provisioning of Signaling Flows
  4. Reporting Capabilities to PCRF
  5. Reporting ICSI Identifier
  6. Access Network Charging Information
    1. Subscription
    2. Notification
  7. Access Network Information
    1. Subscription
    2. Notification
  8. Handling Bearer Path
  9. SBC Support for Video and MSRP Requirements
Info

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.

Subscription

When 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. SBC also subscribes to notifications for changes of the IP-CAN type used by the UE within the same AAR command. SBC includes a "Specific-Action" AVP in the AAR that is set to the value of "IP-CAN_CHANGE".

Call flow 

Caption
0Figure
1IP CAN Subscription and Notification flow

Image Modified

Call flow description

  • The 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 SBC. PCRF responds the type of IP-CAN currently used.

Notification

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 SBC receives a notification of the change of the IP-CAN used by the UE, SBC stores the new IP-CAN type information. The SIP registration procedure is completed successfully. 

Signaling Bearer

Subscription

When SBC receives an initial REGISTER SIP message from an attached UE, it subscribes to the status of the AF Signaling transmission path. 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. 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 SBC.

Caption
0Figure
1Signaling Status Call Flow

Image Modified

Notification

If PCRF is notified the loss or release of resources associated to the PCC/QoS rules corresponding with AF Signaling IP flows, informs 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 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

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. 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.

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. 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

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 SBC after the local resource reservation is completed.

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:

 

Caption
0Figure
1Originating Call Access Network

Image Modified

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, 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 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

SBC requests the PCRF to report the access network information (user location, user timezone), 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. SBC requests PCRF to report the access network information in conjunction with providing PCRF with AF session information. 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 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

Caption
0Figure
1Originating Call for PCSCF

Image Modified

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, 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, 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, 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:

Caption
0Table
1SBC Behaviour
Received PANI header?

Insert P-Access Network Info

PANI transparency flagValidate PANIP-CSCF Behavior
Yes/NoEnableEnabled/disabledEnabled/disabledConstructs and Sends PANI with received location info(Ignores If it received  at ingress side)
Yes/NoDisableEnabled/disabledEnabled/disabledExisting 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 SBC about loss of bearer by sending RAR and SBC terminates the session by sending BYE.  If bearer for other streams is lost , PCRF informs SBC about loss of bearer, 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:

Caption
0Figure
1Handling Bearer Path

Image Modified

Rx Requirements for SBC between UE and P-CSCF

When SBC is placed between UE and P-CSCF, P-CSCF only has access to SBC’s egress IP address and port. It doesn’t have access to UE’s IP address as well as SBC’s 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 SBC ingress IP address in a proprietary extension (SIP header or SDP parameter) to P-CSCF.

For SIP messages heading to P-CSCF from 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:

Code Block
languagenone
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.

Caption
0Figure
1P-UE-Flow-Info

Image Modified

 


Note

When the flag insertUEFlowInfo  is enabled at the core side, SBC inserts "P-UE-Flow-Info" header for all the SIP requests/response messages along with SDP.

SBC Support For Video and MSRP Requirements

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. 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. 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.

Caption
0Table
1AVP List
Parameter NameTypeCodeDescription
Required Access InfoEnumerated536

This field contains the access network information required for that AF session.

The following values are defined:
USER_LOCATION (0), MS_TIME_ZONE (1).
Supported FeatureGrouped628

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 :

Supported-Features ::=

<AVP header: 628 10415 >

{ Vendor-Id }

{ Feature-List-ID }

{ Feature-List }

*[AVP].

IP CAN TypeEnumerated1027

This field indicates the type of Connectivity Access Network in which the user is connected.

The following values are defined:

  • 3GPP-GPRS (0): This value is used to indicate that the IP-CAN is associated with a 3GPP GPRS access that is connected to the GGSN based on the Gn/Gp interfaces and is further detailed by the RAT-Type AVP. RAT-Type AVP will include applicable 3GPP values, except EUTRAN.
  • DOCSIS (1): This value is used to indicate that the IP-CAN is associated with a DOCSIS access.
  • xDSL (2): This value is used to indicate that the IP-CAN is associated with an xDSL access.
  • WiMAX (3): This value is used to indicate that the IP-CAN is associated with a WiMAX access (IEEE 802.16).
  • 3GPP2 (4): This value is used to indicate that the IP-CAN is associated with a 3GPP2 access connected to the 3GPP2 packet core as specified in 3GPP2 X.S0011 [20] and is further detailed by the RAT-Type AVP.
  • 3GPP-EPS (5): This value is used to indicate that the IP-CAN associated with a 3GPP EPS access and is further detailed by the RAT-Type AVP.
  • Non-3GPP-EPS (6): This value is used to indicate that the IP-CAN associated with an EPC based non-3GPP access and is further detailed by the RAT-Type AVP. This field is used to identify the radio access technology that is serving the UE.
RAT TypeEnumerated1032

This field is used to identify the radio access technology that is serving the UE. The following values are defined:

  • WLAN (0): This value is used to indicate that the RAT is WLAN.   
  • VIRTUAL (1): This value is used to indicate that the RAT is unknown. For further details refer to 3GPP TS 29.274 [22].
  • UTRAN (1000): This value is used to indicate that the RAT is UTRAN. For further details refer to 3GPP TS 29.060 [18].
  • GERAN (1001): This value is used to indicate that the RAT is GERAN. For further details refer to 3GPP TS 29.060 [18].
  • GAN (1002): This value is used to indicate that the RAT is GAN. For further details refer to 3GPP TS 29.060 [18] and 3GPP TS 43.318 [29].
  • HSPA_EVOLUTION (1003): This value is used to indicate that the RAT is HSPA Evolution. For further details refer to 3GPP TS 29.060 [18].
  • EUTRAN (1004): This value is used to indicate that the RAT is EUTRAN. For further details refer to 3GPP TS 29.274 [22]
  • CDMA2000_1X (2000): This value is used to indicate that the RAT is CDMA2000 1X. For further details refer to 3GPP2 X.S0011 [20].
  • HRPD (2001): This value is used to indicate that the RAT is HRPD. For further details refer to 3GPP2 X.S0011 [20].
  • UMB (2002): This value is used to indicate that the RAT is UMB. For further details refer to 3GPP2 X.S0011 [20].
  • EHRPD (2003): This value is used to indicate that the RAT is eHRPD. For further details refer to 3GPP2 X.S0057 [24].
NetLoc-Access-SupportEnumerated2824This field indicates whether PCRF support location info or not.
GPP-User-Location-InfoOctet String22This field indicates details of where the UE is currently located.
3GPP-User-Location-Info-TimeTime2812This field indicates the time the UE was last known to be in the location which is reported during bearer deactivation or UE detach procedure.
3GPP-SGSN-MCC-MNCOctet String18

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).

 

Pagebreak