This command
enables/disables encoding and sending of Supported-Features AVP.
Privilege
Security
Administrator, Administrator
Mode
Exec > Global
Configuration > Context Configuration > IMS Authorization Configuration
> Policy Control Configuration
configure > context
context_name
> ims-auth-service
service_name
>
policy-control
Entering the above
command sequence results in the following prompt:
[context_name]host_name(config-imsa-dpca)#
Syntax
Syntax Description
diameter encode-supported-features { adc-rules | netloc | netloc-ran-nas-cause | pending-transactions | session-recovery | session-sync | sgw-restoration | sponsored-connectivity | virtual-apn }
{ default | no } diameter encode-supported-features
adc-rules
This keyword enables
configuration of Application Detection and Control (ADC) rules over Gx
interface. For ADC 6th bit of supported feature will be set. By default, this
supported feature will be disabled.
Important:
ADC Rule support
is a licensed-controlled feature. Contact your Cisco account representative for
detailed information on specific licensing requirements.
This keyword "adc-rules" will be available only when the
feature-specific license is configured.
In release 18, the
gateway node will use ADC functionality over Gx as defined in the Release 11
specification of 3GPP standard. ADC extension over Gx provides the
functionality to notify PCRF about the start and stop of a specific protocol or
a group of protocols, and provide the possibility to PCRF that with the
knowledge of this information, change the QoS of the user when the usage of
application is started and until it is finished.
The provision of ADC
information is done through the ADC rule, the action initiated by PCRF is done
through the PCC rule.
ADC rules are
certain extensions to dynamic and predefined PCC rules in order to support
specification, detection and reporting of an application flow. These rules are
installed (modified/removed) by PCRF via CCA-I/CCA-U/RAR events. ADC rules can
be either dynamic PCC or predefined PCC rules, and the existing attributes of
dynamic and predefined rules will be applicable.
Dynamic PCC rule
contains either traffic flow filters or Application ID. When Application ID is
present, the rule is treated as ADC rule. Application ID is the name of the
ruledef which is pre-defined in the boxer configuration. This ruledef contains
application filters that define the application supported by P2P protocols.
PCEF will process
and install ADC rules that are received from PCRF interface, and will detect
the specified applications and report detection of application traffic to the
PCRF. PCRF in turn controls the reporting of application traffic.
PCEF monitors the
specified applications that are enabled by PCRF and generates Start/Stop events
along with the Application ID. Such application detection is performed
independent of the bearer on which the ADC PCC rule is bound to. For instance,
if ADC rule is installed on a dedicated bearer whereas the ADC traffic is
received on default bearer, application detection unit still reports the start
event to PCRF.
netloc
Enables the NetLoc
feature. The NetLoc feature indicates the support for reporting of the Access
Network Information.
Important:
Network Provided
Location Information (NPLI) feature is a license-controlled feature. A valid
feature license must be installed prior to configuring this feature. Contact
your Cisco account representative for more information.
A new feature
"netloc" (feature bit 10) has been added as part of the Supported-Features AVP
to implement the Network provided Location Info (NPLI) feature for IMS. NPLI is
used to support variety of applications like emergency call, Lawful intercept,
charging, etc.
Important:
This feature works
only if PCRF too supports netloc.
The netloc feature
bit will be sent to PCRF on demand via CCR-I message. A new event trigger
"ACCESS_NETWORK_INFO_REPORT (45)" and a new Diameter AVP "Required-Access-Info"
have been added to support the NPLI enhancement.
The gateway node
provides the required access network information (e.g. user location and/or
user time zone information) to the PCRF within the 3GPP-User-Location-Info AVP,
User-Location-Info-Time AVP (if available), and/or 3GPP-MS-TimeZone AVP as
requested by the PCRF. The gateway also provides the ACCESS_NETWORK_INFO_REPORT
event trigger within Event-Trigger AVP.
netloc-ran-nas-cause
Enables the
Netloc-RAN-NAS-Cause feature. By default, this supported feature will be
disabled.
This feature is used
to send detailed RAN and/or NAS release cause code information from the access
network to PCRF. This feature is added to be in compliance with Release 12
specification of 3GPP TS 29.212. It requires that the NetLoc feature is also
supported.
A new feature
"netloc-ran-nas-cause" (feature bit 22) has been added as part of the
Supported-Features AVP to support the 3GPP RAN/NAS Release Cause Code
Information Element (IE) on Gx interface.
Important:
This feature can
be enabled only when the NetLoc feature license is installed.
If the supported
features "netloc-ran-nas-code" and "netloc" are enabled, then
netloc-ran-nas-cause code will be sent to PCRF via CCR-T message. A new
Diameter AVP "RAN-NAS-Release-Cause" has been added to support this feature.
This AVP will be included in the Charging-Rule-Report AVP and in CCR-T for
bearer and session deletion events respectively.
pending-transactions
Configures the
Pending Transactions feature as part of supported features. This keyword
addition is to handle race conditions on Gx i.e. process the Diameter messages
in the order they are received.
Gx-based
applications are vulnerable to certain race conditions (e.g. concurrent
RAR/CCR). Enhancements are done on the Diameter protocol to deterministically
handle the race conditions on Gx.
In a scenario
wherein RAR is received while waiting for CCA-U, Gx application rejects RAR
with Experimental-Result-Code AVP set to DIAMETER_PENDING_TRANSACTION. This
should be done only if PCRF supports this functionality otherwise Gx client
should continue with the current implementation.
If race conditions
are not processed properly, it can lead to unpredictable behavior from each
node, resulting in subscriber disconnection. With this feature, the outcome in
such situation is deterministic and operator has the ability to influence the
node behavior aligned with their policy.
Important:
Currently only one
pending transaction is supported. So, all other transactions (like handoffs,
etc) while one is pending will be rejected.
In 17.0 and later releases, in order to comply with 4G Network
Upgrade 3GPP Standard, the following changes are implemented:
- Support for Negotiation of PT
in initial session establishment.
- Support for receiving/sending
4144 with 3GPP Vendor ID in CCA/RAA.
- Retry of CCR-U when 4144 is
received from PCRF.
- No Support for 4198 with
Proprietary Vendor ID.
- Recovery of negotiated
Supported features.
session-recovery
Enables the
Session Recovery feature. This functionality helps ensure that the PCRF and
P-GW can be in sync on session information and recover any lost Gx sessions. By
default, session recovery and session sync features are not enabled.
Gx sessions
typically tend to be long-lived. In case of session loss in PCRF (e.g. due to
software failure), or a message loss in PCRF (e.g. Gx:RAA is dropped due to
overload control), there is no existing mechanism to allow the PCRF and P-GW to
sync-up on session state like Rules Status, APN-AMBR, QoS, Event Triggers, etc.
In this release, the Gx interface between P-GW and PCRF has been enhanced to
allow the PCRF and P-GW to sync-up. This is currently not part of 3GPP 29.212.
Important:
In this release,
the Session Recovery and Sync will be supported only for the IMS APN.
This keyword is
used to achieve the session recovery. When this feature is enabled, P-GW and
PCRF will exchange session information and P-GW provides the complete
subscriber session information to enable PCRF to build the session state.
session-sync
Enables the
Session Synchronization feature. This functionality helps ensure that the PCRF
and P-GW can be in sync on session information and recover any lost Gx
sessions. By default, Session Recovery and Session Sync features will not be
enabled.
Gx sessions
typically tend to be long-lived. In case of session loss in PCRF (e.g. due to
software failure), or a message loss in PCRF (e.g. Gx:RAA is dropped due to
overload control), there is no existing mechanism to allow the PCRF and P-GW to
sync-up on session state like Rules Status, APN-AMBR, QoS, Event Triggers, etc.
The Gx interface between P-GW and PCRF is enhanced to allow the PCRF and P-GW
to sync-up. This is currently not part of 3GPP 29.212.
Important:
In this release,
the Session Recovery and Sync will be supported only for the IMS APN.
This keyword is
used to achieve the session sync-up. When this feature is enabled, P-GW and
PCRF will exchange session information and P-GW provides the complete
subscriber session information to enable PCRF to build the session state.
sgw-restoration
This keyword
enables configuration of S-GW Restoration feature.
P-GW is configured
to support S-GW Restoration feature. P-GW sends S-GW Restoration feature in
Supported-Features AVP through the CCR-I message during session creation. If
P-GW receives S-GW Restoration feature in Supported-Features AVP in CCA-I
message, then P-GW enables S-GW Restoration feature.
If P-GW and PCRF
support S-GW Restoration feature, then the P-GW accepts CCA and RAR during S-GW
restoration. Only Rule removal or RAR with session release cause is processed.
Any rule install or modify is dropped. P-GW triggers CCR-U with PCC rule
failure report and AN_GW_STATUS AVP to inform PCRF that S-GW is down. After
receiving the SGW_Restoration indication, PCRF does not initiate any rule
install or modification towards the P-GW. The P-GW informs the PCRF when the
S-GW has recovered using the Event-Trigger AVP set to AN_GW_CHANGE and
including the AN-GW-Address AVP related to the restored or new S-GW. If S-GW
restoration is reported to PCRF, then the P-GW sends CCR-U with AN_GW_CHANGE
trigger.
If S-GW
Restoration feature is not negotiated through the Supported-Features AVP, then
P-GW falls back to the old behavior as follows:
- Drops all internal updates towards
PCRF
- Rejects CCA and RAR during S-GW
Restoration
- Does not include AN_GW_STATUS as
AN_GW_FAILED (0) AVP in CCR-U
- Sends an RAA command with the
Experimental-Result-Code set to UNABLE_TO_COMPLY (5012) upon receiving RAR
command
After configuring
the S-GW Restoration feature on Gx interface, the failure is sent to PCRF with
Rule-Failure-Code as AN_GW_FAILED in both failure and restoration scenarios.
sponsored-connectivity
Enables the
Sponsored (data) Connectivity feature.
With sponsored
data connectivity, the sponsor has a business relationship with the operator
and the sponsor reimburses the operator for the user's data connectivity in
order to allow the user access to an associated Application Service Provider's
(ASP) services. Alternatively, the user pays for the connectivity with a
transaction which is separate from the subscriber's charging. It is assumed the
user already has a subscription with the operator.
The purpose of
this feature is to identify the data consumption for a certain set of flows
differently and charge it to sponsor. To support this, a new reporting level
"SPONSORED_CONNECTIVITY_LEVEL" is added for reporting at Sponsor Connection
level and two new AVPs "Sponsor-Identity" and
"Application-Service-Provider-Identity" have been introduced at the rule level.
This CLI command
"diameter
encode-supported-features" has been added in Policy Control
Configuration mode to send Supported-Features AVP with Sponsor Identity.
Sponsored
Connectivity feature will be supported only when both P-GW and PCRF support
3GPP Rel. 10. P-GW advertises release as a part of supported features in CCR-I
to PCRF. If P-GW supports Release 10 and also Sponsored Connectivity but PCRF
does not support it (as a part of supported features in CCA-I), this feature is
turned off.
This feature
implementation impacts only the Gx dictionary "dpca-custom15".
virtual-apn
This keyword
enables configuration of Gx-based Virtual APN (VAPN) feature. For VAPN 4th bit
of supported feature will be set. By default, this supported feature will be
disabled.
Important:
Gx-based VAPN is
a licensed-controlled feature. Contact your Cisco account representative for
detailed information on specific licensing requirements.
This keyword
"virtual-apn"
will be available only when the feature-specific license is configured.
In releases prior
to 19, VAPN selection was possible through RADIUS or local configuration. In
Release 19, ASR5K uses PCRF and Gx interface for Virtual APN selection to
achieve signaling reduction.
This keyword
enables Gx based Virtual APN Selection feature for a given IMS authorization
service. When this configuration is enabled at P-GW/GGSN, then P-GW/GGSN
advertises this feature to PCRF through the Supported-Features AVP in CCR-I.
When the VAPN is selected, then the PCRF rejects the CCR-I message with the
Experimental-Result-Code AVP set to 5999 (DIAMETER_GX_APN_CHANGE), and sends a
new APN through the Called-Station-Id AVP in CCA-I message. The existing call
is then disconnected and established with the new virtual APN. Note that the
Experimental Result Code 5999 will have the Cisco Vendor ID.
Important:
Enabling this
feature might have CPU impact (depending on the number of calls using this
feature).
Limitations:
- Virtual APN
supported feature negotiation, Experimental Result Code (5999),
Called-Station-Id AVP should be received to establish the call with new virtual
APN. When any one of conditions is not met then the call will be terminated.
- Failure-handling will not be taken into account for 5999
result-code when received in the CCA-I message.
- When the
Experimental Result Code 5999 is received in the CCA-U then failure-handling
action will be taken.
- If the
Called-Station-Id AVP is received in CCA-U or CCA-T, then the AVP will be
ignored.
- If virtual-apn
is received in local-policy initiated initial message then the call will be
terminated.
- When PCRF
repeatedly sends the same virtual-apn, then the call will be terminated.
default | no
This keyword
removes the previously configured supported features.
Usage Guidelines
This command is
used to enable encoding and sending of Supported-Features AVP.