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
diameter encode-supported-features { adc-rules | cno-uli | conditional-apn-policy-info | conditional-policy-info | conditional-policy-info-default-qos | extended-bw-newradio | mission-critical-qcis | multiple-pra | netloc | netloc-ran-nas-cause | pcscf-restoration-ind | pending-transactions | session-recovery | session-sync | sgw-restoration | sponsored-connectivity | trusted-wlan | netloc-trusted-wlan | netloc-untrusted-wlan | 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.
cno-uli
This keyword enables the Presence Reporting Area (PRA) feature.
Configuring cno-uli keyword enables feature bit in supported feature AVP and
helps in negotiating with PCRF.
The Presence Reporting Area is an area defined within the 3GPP packet
domain for the purpose of reporting of UE presence within that area. This is
required for policy control and in charging scenarios.
During an IP-CAN session, the PCRF determines whether the reports for
change of the UE presence in the PRA are required for an IP-CAN session. This
determination is made based on the subscriber's profile configuration and the
supported AVP features.
conditional-apn-policy-info
This keyword
enables the Conditional APN Policy Information feature. This feature bit
support is added to enable this feature for negotiation with PCRF. By default,
this supported feature is disabled.
Use all three
keywords—conditional-apn-policy-info, conditional-policy-info,
conditional-policy-info-default-qos—to enable conditional Policy information
feature on the P-GW. Using the no form of the command for all the three
keywords, disables this feature.
Using only one of
the keywords enables the feature bit in supported feature AVP.
Using no form of
this command with only one of the keywords disables a specific feature bit in
negotiation of this feature.
Important |
This keyword is
customer-specific. For more information, contact your Cisco account
representative.
|
conditional-policy-info
This keyword
enables the Conditional Policy Information feature. This feature bit support is
added to enable this feature for negotiation with PCRF. By default, this
supported feature is disabled.
Use all three
keywords—conditional-apn-policy-info, conditional-policy-info,
conditional-policy-info-default-qos—to enable conditional Policy information
feature on the P-GW. Using the no form of the command for all the three
keywords, disables this feature.
Using only one of
the keywords enables the feature bit in supported feature AVP.
Using no form of
this command with only one of the keywords disables a specific feature bit in
negotiation of this feature.
Important |
This keyword is
customer-specific. For more information, contact your Cisco account
representative.
|
conditional-policy-info-default-qos
This keyword
enables the Conditional Policy Information Default QoS feature. This feature
bit support is added to enable this feature for negotiation with PCRF. By
default, this supported feature is disabled.
Use all three
keywords—conditional-apn-policy-info, conditional-policy-info,
conditional-policy-info-default-qos—to enable conditional Policy information
feature on the P-GW. Using the no form of the command for all the three
keywords, disables this feature.
Using only one of
the keywords enables the feature bit in supported feature AVP.
Using no form of
this command with only one of the keywords disables a specific feature bit in
negotiation of this feature.
Important |
This keyword is
customer-specific. For more information, contact your Cisco account
representative.
|
extended-bw-newradio
This keyword enables Extended Bandwidth with New-Radio feature.
mission-critical-qcis
This keyword
enables Mission Critical (MC)-Push to Talk (PTT) (MC-PTT) QCI feature. By
default, this feature will not be enabled.
Important |
This keyword can
be enabled only if the Wireless Priority Feature Set (WPS) license is
configured. For licensing information, contact your Cisco account or support
representative.
|
To support the
MC-PTT services, a new set of standardized QoS Class Identifiers (QCIs) (65,
66, 69, 70) have been introduced. These are 65-66 (GBR) and 69-70 (non-GBR)
network-initiated QCIs defined in 3GPP TS 23.203 v13.6.0 and 3GPP TS 23.401
v13.5.0 specifications. These QCIs are used for Premium Mobile Broadband
(PMB)/Public Safety solutions.
In releases prior
to 21, the gateway accepted only standard QCIs (1-9) and operator defined QCIs
(128-254). If the PCRF sends QCIs with values between 10 and 127, then the
gateway rejected the request. The MC QCI support was not negotiated with PCRF.
In 21 and later releases, PCRF accepts the new standardized QCI values 69 and
70 for Default Bearer creation and 65, 66, 69 and 70 for Dedicated Bearer
creation.
When
mission-critical-qcis option is enabled, the
gateway allows configuring MC QCIs as a supported feature and then negotiates
the MC-PTT QCI feature with PCRF through Supported-Features AVP.
The gateway
rejects the session create request with MC-PTT QCIs when the WPS license is not
enabled and Diameter is not configured to negotiate MC-PTT QCI feature, which
is part of Supported Feature bit.
To disable the
negotiation of this feature, the existing
no diameter
encode-supported-features command needs to be configured. On
executing this command, none of the configured supported features will be
negotiated with the PCRF.
For more
information on this feature, see the
Gx Interface
Support chapter in the administration guide of the product you are
deploying.
multiple-pra
Enables the Multiple Presence Reporting Area Information Reporting.
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.
Starting from Release 21.2, this feature is supported on S5/S8,
and S2b interfaces.
Important |
This feature can
be enabled only when the NetLoc feature license is installed. However, from
StarOS Release 21.1, you can enable the RAN/NAS feature without configuring the
NetLoc feature. It is not mandatory to configure the "netloc" keyword to
configure the "netloc-ran-nas-code" keyword.
|
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.
pcscf-restoration-ind
Enables the P-CSCF Restoration Indication feature. By default, this feature is disabled.
Important |
This keyword is license dependent. For more information, contact your Cisco account representative.
|
This keyword, when enabled, allows the negotiation of P-CSCF Restoration feature support with PCRF. A new Diameter AVP “PCSCF-Restoration-Indication” is introduced to indicate to PCEF that a P-CSCF Restoration is requested. This is achieved by setting AVP value to 0.
For more information on this feature, see the Gx Interface Support chapter in the administration guide of the product you are deploying.
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".
trusted-wlan
Enables the
Trusted WLAN feature.
netloc-trusted-wlan
Enables the NetLoc
trusted WLAN feature over Gx interface.
This command takes
effect when Gx is enabled on S2b call. By default, the feature is disabled and
TWAN information will not be sent over Gx.
netloc-untrusted-wlan
Enables the NetLoc
untrusted WLAN feature over Gx interface.
This command takes
effect when Gx is enabled on S2b call. By default, the feature is disabled and
UWAN information will not be sent over Gx.
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.