This section describes the various use case scenarios that can lead to creation, modification, and deletion of QoS-Profile and the corresponding actions taken.

QoS-Profile associated to the PDU Context will be modified in the following scenarios:

• Response from PCF for SMPolicyContextData

• Update Notify from PCF

• Update response from PCF on behalf of Update request sent initially from SMF

• Update request from SMF will be triggered in the following cases:

  • UE triggered modify request

  • AN triggered modify request

  • UDM triggered modify request

The UDM NF maintains the subscribed QoS for the UE in the Session Management Subscription Data. During the PDU setup procedure, the SMF posts an HTTP2 GET request (see 3GPP TS 29.503) for a resource URI "/{supi}/sm-data" to fetch the Session Management Subscription Data. The subscription data has a set of DNN configurations, one for each DNN which the subscriber is allowed to access. Each DNN configuration consists of the following parameters:

• sessionAMBR: The maximum aggregated uplink and downlink bit rates to be shared across all non-GBR QoS flows in each PDU session.

• 5gQosProfile: The default 5G QoS Indicator (5QI) and default ARP values are provided to the SMF in the Session Management Subscription Data in this attribute of the DNN configuration.

The SMF saves the subscribed QoS parameters and sends this across to the PCF during the SM Policy Association Establishment procedure.

The SMF negotiates the QoS with the PCF by initiating a Policy Association Establishment procedure as defined in 3GPP TS 23.502, section 4.16.4. The sessionAMBR and 5gQosProfile parameters that are received from subscription are included in the Npcf_SMPolicyControl_Create request to PCF. The response from PCF may contain the following:

• Session Rules: A session rule consists of policy information elements that are associated with the PDU session. The QoS related information is Authorized session AMBR and Authorized default QoS.

  • Policy Charging and Control (PCC) Rules: The PCC rule includes the FlowDescription, FlowDirection, and RefQosData parameters among other information. There could be one or more PCC rules in the response from PCF.

    • FlowDescription: This parameter contains packet filters for IP flows. For IP PDU Session Type, the Packet Filter Set supports packet filtering based on at least any combination of:

      - Source / Destination IP address or IPv6 prefix

      - Source / Destination port number

      - Protocol ID of the protocol above IP/Next header type

      - Type of Service (TOS) (IPv4) / Traffic class (IPv6) and mask

      - Flow Label (IPv6)

      - Security parameter index

    • FlowDirection: This parameter indicates the direction of data traffic on which the rule has to be applied. This could be UPLINK, DOWNLINK, or BIDIRECTIONAL.

    • RefQosData: This parameter refers to the QoS description to be applied to this PCC Rule. This matches the QosId of at least one of the QoS Description entries in the response from PCF.

  • QoS Characteristics: The QoS characteristics include parameters such as:

    • Resource Type (GBR, Delay critical GBR, or non-GBR)

    • Priority Level

    • Packet Delay Budget

    • Packet Error Rate

    • Averaging Window

    • Maximum Data Burst Volume (for the Delay-critical GBR resource type only)

      This attribute in the response from PCF is meant to be used only for non-standard 5QI values. For standard 5QI values, the characteristics are already defined in 3GPP TS 23.501, section 5.7.4.

  • QoS Description: The QoS Description parameter consists of the following:

    • 5QI: Standard or non-standard from the QoS Characteristics attribute

    • Uplink and Downlink GBR

    • Uplink and Downlink MBR

    • Maximum Packet Loss Rate

    • QosId – Referenced in PCC rules

    • Default QoS Indication

      There could be more than one QoS Description attribute in the response from PCF.

The information, that is received from PCF in the Npcf_SMPolicyControl_Create response, is used to create and update QoS Flows in the SMF. Each QoS flow has a unique QoS Flow ID (QFI) and one or more PCC rules map to a single QoS flow.

The following figure illustrates how to manage the QoS information at the SMF.

Each QoS Flow in SMF is a combination of three sets of information:

• QoS profile: A QoS profile stores all QoS attributes for a particular QoS Flow.

  • Some QoS parameters known as the QoS flow binding parameters make a unique combination for one QoS Flow of one PDU Session. This means that, for a PDU session, each unique combination of these parameters represents a separate QoS Flow. These parameters are – 5QI, ARP, Priority, Maximum Data Burst Volume, Average Window and QNC.

  • If the 5QI for the QoS profile of a QoS Flow is non-standard, some additional QoS characteristics such as Resource Type, Packet Delay Budget, Packet Error rate, and Averaging Window are also saved in the QoS profile.

  • The QoS profile also maintains multiple QoS Descriptions, each with a unique QoSId for a specific PDU session. Each QoS Description contains the uplink and downlink GBR, uplink and downlink MBR, maximum packet loss rate and default QoS indication.

• QoS Rules: A QoS rule is a collection of packet filters that associates with a particular QoS Description in the QoS profile of the QoS flow. The packet filters directly map to the flow descriptions received in the PCC rules in the Npcf_SMPolicyControl_Create response from PCF. The QoS rules have a reference to the QoSId of the QoS Descriptions that the rules associate with.

• PDRs: Each QoS rule maps to two Packet Detection Rules (PDR) to be sent to the UPF. One PDR is for uplink direction and the other PDR is for downlink direction. The Service Data Flow (SDF) filters in the Packet Detection Information (PDI) attribute within the PDRs map the packet filters of the QoS rule. Each PDR then maps to a Forwarding Action Rule (FAR), which determines the forwarding action for the packets matching the SDF filters. Each PDR is also associated to a QoS Enforcement Rule (QER) which carries the QoS information and it maps to the QoS description associated with the QoS rule.

The negotiated QoS mainly needs to be communicated to the UE (N1 interface using NAS protocol), gNB (N2 interface using NGAP protocol), and UPF (N4 interface using PFCP protocol).

• N1 Interface: On the N1 interface, the session management messages are exchanged between UE and SMF through AMF. The NAS messages are encoded into an N1 container and sent to SMF or received from SMF.

  • All the negotiated/authorized QoS related information that needs to be sent out to the UE are found in the Authorized QoS rules and Session-AMBR attributes of the PDU SESSION ESTABLISHMENT ACCEPT message in an N1 container, during the PDU session establishment (see 3GPP TS 24.501, section 8.3.2).

  • The PDU SESSION MODIFICATION REQUEST message from UE contains the Requested QoS Rules during the UE initiated QoS modification.

  • The Authorized QoS rules and Session-AMBR attributes are also present in the PDU SESSION MODIFICATION COMMAND message sent from SMF to UE during the PCF/SMF initiated QoS modification.

  • The format of the QoS Rule NAS attribute is defined in 3GPP TS 24.501, section 9.10.4.9. This attribute mainly consists of the packet filter list, QFI, and QoS parameters on a per QoS rule basis. This information is available in the QoS rule within the QoS flow.

• N2 Interface: On the N2 interface, SMF sends an N2 container to the gNB through AMF. The N2 container is ASN.1 encoded data and consists of specific information elements of NGAP messages. All the QoS related information to gNB is encoded and sent/received in N2 containers to/from SMF. The NGAP IEs and the corresponding NGAP messages that will finally carry the IE from AMF to gNB are listed in 3GPP TS 29.502, section 6.1.6.4.3.

  • During the PDU session setup, the SMF sends N1N2MessageTransfer to AMF with the N2 container in the PDU Session Re-source Setup Request Transfer IE. This IE contains PDU Session Aggregate Maximum Bit Rate and QoS Flow Setup Request List. The QoS Flow Setup Request List contains QoS Flow Level QoS Parameters (GBR flow information, 5QI, and so on). These are defined in 3GPP TS 38.413, section 9.3.1.

  • Similar information (QoS Flow Level QoS Parameters) is also sent by SMF in the PDU Session Resource Modify Request Transfer IE in an N2 container during the PCF/SMF initiated QoS Modification procedure.

    The information required to create the N2 container in SMF is present in the QoS profile of a QoS flow as described in the previous section.

• N4 Interface: On the N4 interface, the SMF sends the QoS information in the form of Packet Detection Rule (PDR), Forwarding Action Rule (FAR), and QoS Enforcement Rule (QER).

  • The PDR contains the SDF filters in the PDI IE. These SDF filters are the packet filters set in the QoS Rule of a QoS flow.

  • The QER contains the QoS parameters as per the QoS Description to which the QoS rule is associated.

    The contents of PDR, FAR, and QER are defined in 3GPP TS 29.244.

QoS modification may result in one of the following scenarios:

• QoS Flow Addition: Whenever a negotiated QoS is received from PCF either as part of UE initiated modification or PCF initiated QoS modification, the SMF extracts the received QoS Flow Binding Parameters (5QI, ARP, Priority, Max Data Burst Volume, QNC). If there is no QoS Flow with the received combination of the flow binding parameters, SMF adds a new QoS flow and the received PCC rules will be mapped against the new QoS flow. As a result, the new QoS flow rules/QoS descriptions/PDR/QER are created and the corresponding interfaces (N1, N2, and N4) are updated by creating new flows.

• QoS Flow Modification: Whenever a negotiated QoS is received from PCF either as part of UE initiated modification or PCF initiated QoS modification, the SMF extracts the received QoS Flow Binding Parameters (5QI, ARP, Priority, Maximum Data Burst Volume, QNC). If there exists a QoS flow with the same combination of binding parameters, the QoS profile, QoS rules, PDR, and QER for that QoS flow are updated on N1, N2 and N4 interfaces.

The following procedure explains how the SMF handles the modification of authorized default QoS in 4G and WiFi sessions.

1. The SMF receives SmPolicyUpdateNotify from PCF with changed QCI/5QI in AuthorizedDefaultQoS and/or a different session AMBR value.

2. The SMF initiates Update Bearer Request towards S-GW for the default bearer.

   1. In the Update Bearer Request, Bearer Context IE is included for the default bearer and the corresponding Bearer QoS is updated with the changed QCI value.

   2. For the 4G session, the extended Protocol Configuration Options (ePCO), if supported, is included in the Update Bearer Request message. The ePCO includes 5G Authorized QoS Flow Information with updated QCI value for the default flow when the interworking (IWF) is enabled for the session. Otherwise, PCO IE is sent with the same details.

   3. For the WiFi session, Additional Protocol Configuration Options (APCO) is included in the Update Bearer Request message. The APCO contains 5G Authorized QoS Flow Information with updated QCI value for the default flow.

3. The SMF accepts the Update Bearer Response from S-GW.

4. On the N4 interface, the following changes are done:

   1. New instance of the BearerLvlInfo IE is included with the changed QCI value for default bearer tunnel.

   2. Update PDR is sent for all PDRs which are a part of default flow to reflect the association with the new BearerLvlInfo IE.

   3. FAR associated with all PDRs in the default flow is updated with the new DSCP marking value if the 5QI-DSCP mapping configuration has a different value for the changed 5QI.

The following procedure explains how the SMF handles the modification of authorized QoS for the default bearer in a 5G session.

1. The SMF receives SmPolicyUpdateNotify from PCF with changed 5QI in AuthorizedDefaultQoS and/or a different session AMBR value.

2. The SMF initiates N1N2MessageTransfer procedure with AMF to send N1 PDU Session Modification Command and N2 PDU Session Resource Modify Request Transfer IE in this message.

   1. In the N1 message, the default QoS flow is modified in Authorized QoS Flow Description IE to update the 5QI value.

   2. In the N1 message, the Mapped EPS Bearer Context IE is modified to update the QCI of the default bearer.

   3. In the N2 message, the QoS flow level QoS parameter for the default flow is modified to update the 5QI value.

3. The SMF accepts the SMContextUpdate Request from AMF with the responses for the N1 and N2 requests sent in N1N2Message Transfer message.

4. On the N4 interface, the following changes are done:

   1. New instance of the BearerLvlInfo IE is included with the changed 5QI to QFI mapping.

   2. Update PDR is sent for all PDRs which are a part of default flow to reflect the association with the new BearerLvlInfo IE.

   3. Forwarding Action Rule (FAR) associated with all PDRs in the default flow is updated with the new DSCP marking value if the 5QI-DSCP mapping configuration has a different value for the changed 5QI.

The following procedure explains how the SMF handles the modification of authorized default QoS during WiFi handover and other handovers.

1. The SMF sends SMPolicy Update Request to the PCF at the end of each handover procedure. For example, when the PCF arms different policy triggers, the SMF sends SMPolicy Update Request to the PCF. The response from PCF contains the changed QCI in Session Rule (Authorized Default QoS). The SMF initiates the modification procedure towards RAN/UE, and communicates the same information on N1, N2, N4, and S5 interfaces.

2. For all handovers (excluding WiFi-NR/EPS and NR/EPS-WiFi), the SMF sends SMPolicy Update Request to the PCF indicating the RAT type change. The response from PCF contains the changed QCI in Session Rule (Authorized Default QoS). The SMF initiates the modification procedure towards RAN/UE, and communicates the same information on N1, N2, N4, and S5 interfaces.

The handovers involving WiFi are different from the other handovers. The SMF triggers SMPolicy Update Request towards PCF during the handover and not after the handover. For the handovers involving WiFi, the target RAN installs the flows and bearers as new instead of an update. The SMF sends the latest QCI received in the response from PCF while installing the default flow and bearer during the handover.

For a 5G session, the modification of QCI/5QI typically does not fail on the N1 or N2 interface as the default flow is a non-GBR flow and no resource reservation is required for the QCI/5QI modification. However, if the modification procedure fails due to no N1 or N2 responses from AMF, the modification is rolled back and the session continues with the old QCI/5QI and session AMBR values. If the N2 rejects the flow modification, the session is deleted as it cannot remain without the default flow.

For a 4G session, the Update Bearer response does not fail for default bearer modification. However, if the Update bearer Response is missing or if it fails, the modification is rolled back and the session continues with the old 5QI and session AMBR values.

For both 4G and 5G sessions, if the N4 update fails or the response is not received, then the SMF takes the action according to the UPF failure handling template configuration. For 4G and WiFi sessions, if there is a failure on the N4 interface, another Update Bearer Request is sent with the old 5QI and AMBR values to S-GW and ePDG respectively.

The failure handling mechanism remains the same for the PCF-initiated modification procedure.

The Authorized QoS Handling for Default Bearer feature has the following limitations:

• The SMF supports only the standard QCI/5QI change in authorized default QoS IE of the Session Rules. It does not support any change to the Guaranteed Bit Rate (GBR) QCI/5QI of authorized QoS. The SMF rejects any request for modification of QCI/5QI of a QoS data associated with Policy and Charging Control (PCC) rule.

• The SMF does not support QCI/5QI change for dynamic rules.

• The SMF supports QCI/5QI change only for predefined and static rules that are associated to the default bearer. If a predefined rule is associated with a non-default flow or bearer, the SMF does not support QCI/5QI change for that rule.

• The combination of QoS flow binding parameters, such as 5QI, ARP, and so on, for the authorized QoS never remains the same as that of a dedicated bearer or flow. That is, change in QCI/5QI should not result in the default flow having the binding parameters similar to another flow.

• The SMF does not support changes to any other binding parameter including Allocation and Retention Priority (ARP) except the QCI/5QI (with or without session AMBR) in the Session Rules.

• When the QCI/5QI changes, the existing default bearer flow is modified towards N1, N2, and N4 interfaces. In this case, the SMF does not delete the existing flow instead creates a new flow.

The SMF maintains the label "SESSRULE_CHANGE" to indicate any changes to the AMBR value, QCI/5QI value, or a combination of both AMBR and QCI/5QI values.

Use the show running-config profile smf CLI command to verify if the feature is enabled. When enabled, the following field will be displayed as part of the show command output:

• mode offline

The SMF and the PCF negotiate the supported features during Policy Context Creation and during PDU session establishment. Based on the negotiated features, the PCF provides the relevant information.

The following table lists the features that can be negotiated as defined in the 3GPP specification 29.512.

The SMF sends supportedFeatures attribute in the Npcf_SMPolicyControl_Create message, and further includes a bitmap representing the supported features. The PCF also sends the supportedFeatures attribute in the response message. The response should either match or be a subset of the request.

The string contains a bitmask indicating supported features in hexadecimal representation. Each character in the string takes a value of "0" to "9" or "A" to "F" and represents the support of the features as described in the preceding table. The most significant character representing the highest-numbered features appears first in the string, and the character representing features 1–4 appears last in the string. The list of features and their numbering (starting with 1) are defined separately for each API.

For the N4 interface, the SMF sends the QoS information in the form of:

• Packet Detection Rule (PDR)

• Forwarding Action Rule (FAR)

• QoS Enforcement Rule (QER)

The SessionAMBR includes the maximum aggregated uplink and downlink bit rates to be shared across all non-GBR QoS flows in each PDU session. The SMF sends the session level QER for non-GBR flows along with existing QER to the UPF.

The SMF receives sessionRule from PCF in SmPolicyDecision during PDU session creation. The sessionRule consists of authSessAmbr and authDefQos. The authorized AMBR consists of the Uplink (UL) and Downlink (DL) MBR at a session level and authDefQos contains the 5Qi, ARP, and other QoS binding parameters for the default QoS flow.

The SMF performs the following actions:

• Any PCC rules received from the PCF that have an associated QoS Desc with the same binding parameters as received in authDefQos are tagged with the default QoS flow.

• On the N4 interface, the UL and DL Packet Detection Rules (PDRs) are created for each PCC rule that is associated with the default QoS flow. For session AMBR enforcement, the SMF creates a QoS Enforcement Rule (QER) with appropriate AMBR and associates it with all PDRs for non-GBR rules.

• On the N1 interface, the "QoS Flow Description" attribute in the PDU SESSION ESTABLISHMENT ACCEPT message contains the QFI and MFBR and 5Qi values. The Session AMBR is also sent in this message.

• On the N2 interface, the PDU Session Resource Setup Transfer Request IE contains the AMBR and the "QoS flow level QoS parameters" (5Qi, ARP, and so on) and QFI.

• The SMF supports the UDM-initiated Session AMBR modification. In this case:

  • The SMF sends Npcf_SMPolicyControl_Update to the PCF along with the new subscribed session AMBR within the "subsSessAmbr" attribute and the SE_AMBR_CH policy control request trigger within the "repPolicyCtrlReqTriggers". On receiving the change of session AMBR, the PCF provisions the new authorized session AMBR to the SMF in the response.

  • Update the QERs on N4 interface for Session AMBR enforcement.

  • Initiate N1N2MessageTransfer towards the AMF with Sess AMBR in PDU SESSION MODIFICATION COMMAND message in N1 interface and PDU Session Resource Modify Request transfer IE in N2 container having the new AMBR.

The PCF can create, modify, or delete multiple GBR and non-GBR PCC rules.

The following scenarios are possible:

1. Multiple non-GBR and GBR PCC rules are activated during PDU session establishment. In this case:

   1. The SMF creates the QoS flow according to the QoS flow binding principle as described in the QoS Management section.

   2. On the N4 interface, the UL and DL PDRs are created for each PCC rule that is associated with all the flows. For flow-level QoS enforcement, the SMF creates QERs with the MFBR and GFBR (for GBR flows) values and associates it with each PDR of a flow.

   3. On the N1 interface, the "QoS Flow Description" attribute in the PDU SESSION ESTABLISHMENT ACCEPT message contains the QFI and MFBR, GFBR, and 5Qi values. The packet filters associated with each QoS rule are sent on the N1 interface in the "Authorized QoS Rules" attribute.

   4. Different types of packet filters are supported on both the N4 and the N1 interfaces. This list includes:

      
      Packet filter component type identifier 
      Bits 
      8 7 6 5 4 3 2 1 
      0 0 0 0 0 0 0 1 Match-all type 
      0 0 0 1 0 0 0 0 IPv4 remote address type 
      0 0 0 1 0 0 0 1 IPv4 local address type 
      0 0 1 0 0 0 0 1 IPv6 remote address/prefix length type 
      0 0 1 0 0 0 1 1 IPv6 local address/prefix length type 
      0 0 1 1 0 0 0 0 Protocol identifier/Next header type 
      0 1 0 0 0 0 0 0 Single local port type 
      0 1 0 0 0 0 0 1 Local port range type 
      0 1 0 1 0 0 0 0 Single remote port type 
      0 1 0 1 0 0 0 1 Remote port range type 
      

   5. On the N2 interface, the PDU Session Resource Setup Transfer Request IE contains the "QoS flow level QoS parameters" (5Qi, ARP, and so on) and QFIs for each of the flows. The "GBR QoS Flow Information" field of the IE contains the MFBR and GFBR of the GBR flows.

2. Modification of PCC rules after PDU session establishment. In this case, the following scenarios are observed:

   1. Modification, addition, and removal of packet filters of one or more PCC rules:

      1. In this case, the SDF filters of the PDR on the N4 interface are changed by invoking N4 session modification.

      2. The SMF initiates N1N2MessageTransfer towards the AMF with "Authorized QoS Rules" attribute in PDU SESSION MODIFICATION COMMAND message in N1 interface. The rule operation code in this attribute is one of the following:

         
         0 1 1 Modify existing QoS rule and add packet filters 
         1 0 0 Modify existing QoS rule and replace all packet filters 
         1 0 1 Modify existing QoS rule and delete packet filter 
         

   2. Change in QoS associated with one or more PCC rules:

      1. The SMF performs QoS flow binding evaluation which in turn results in the following operations:

         1. Addition of a new QoS flow results in change of QFI on the N4 interface for some of the PDRs.

         2. Movement of a PCC rule from one QoS flow to another QoS flow. In this case, the PDR/QER of impacted PCC rules are modified to update the QFI.

         3. Removal of a QoS flow when the last PCC rule in that flow is moved to a different QoS flow. In this case, the PDR/QER of impacted PCC rules are modified to update the QFI.

      2. In the preceding cases, on the N1 interface the Authorized QoS Rules and Authorized QoS Descriptors are sent with the operation code as one of the following:

         
         0 0 1 Create new QoS flow description 
         0 1 0 Delete existing QoS flow description 
         0 1 1 Modify existing QoS flow description 
         

      3. On the N2 interface, QoS Flow Level QoS parameters of the PDU Session Resource Modify Request transfer IE carry the modified GFBR, MFBR, 5Qi and so on. For any flow removal, the QoS Flow to re-lease List is included in this IE.

   3. PCC rule removal:

      1. In this case, the SMF removes all the PDRs associated with a QoS flow on the N4 interface.

      2. On the N1 interface, the Authorized QoS Rules and Authorized QoS Descriptors are sent with the operation code as one of the following:

         
         0 1 0 Delete existing QoS flow description 
         

      3. On the N2 interface, the PDU Session Resource Modify Request transfer IE carries the QoS Flow to release List.

The SMF enforces QoS at PCC rule (SDF) level, QoS flow level, and session level by creating one QER:

• per PCC rule level to enforce MBR/GBR as per the associated QoS Desc supplied by PCF and associated to the given PCC rule.

• at QoS flow level which has aggregated MBR/GBR of all the PCC rules associated with a QFI.

• at session level to enforce the Session AMBR for all non-GBR QoS flows.

Once these QERs are created, the SMF associates:

• the session level QER to all PDRs belonging to the non-GBR QoS category.

• the SDF level QER to each individual PCC rule.

For any QoS modification including movement of the PCC rules from one flow to another and QoS modification within flow, the SMF modifies the GFBR/MFBR (or Session AMBR) and updates the QERs accordingly on the N4 interface.

The PCF provides one or more policy control request trigger(s) by including the triggers in the "policyCtrlReqTriggers" attribute(s) in the SmPolicyDecision data structure.

During the lifetime of the PDU session, the PCF updates or removes the policy control request triggers. To update the trigger, the PCF provides a new complete list of applicable policy control request triggers by including the trigger(s) in the "policyCtrlReqTriggers" attribute.

The PCF removes all previously provided triggers by providing a "policyCtrlReqTriggers" attribute set to NULL value. Upon reception of a policy control request trigger with this value, the SMF does not inform PCF of any trigger except for those triggers that are always reported and does not require provisioning from the PCF.

Whenever the PCF provisions the trigger, unless otherwise specified in the trigger's value definition, the SMF sends the corresponding currently applicable values (for example, access type, RAT type, user location information, and so on) to the PCF within the UeCampingRep data structure in the response of the HTTP POST message. In this case, the "repPolicyCtrlReqTriggers" attribute is not included.

The list of supported triggers is as follows:

Support SCNN_CH Trigger in Handovers

The SMF supports the serving network change trigger in the following handovers:

• Inter AMF Handover: If the "SCNN_CH" is provisioned, when the SMF detects a change of serving Network Function (for example, the AMF), the SMF includes the "SCNN_CH" within the "repPolicyCtrlReqTriggers" attribute and the current serving Network Function in the "servNfId" attribute. When the serving Network Function is an AMF, the SMF includes the AMF Network Function Instance Identifier within the "servNfInstId" attribute and the Globally Unique AMF Identifier within the "guami" attribute.

• 5G to 4G handover: When the UE handed over from the 5GS to EPC/E-UTRAN, the SMF includes, if the "SCNN_CH" policy control request trigger is provisioned and met, the "servNfId" attribute including the S-GW identification within the "anGwAddr" attribute.

• 4G to 5G handover: The SMF includes the AMF Network Function Instance Identifier within the "servNfInstId" attribute and the Globally Unique AMF Identifier within the "guami" attribute.

• WiFi to 5G handover: The SMF includes the AMF Network Function Instance Identifier within the "servNfInstId" attribute and the Globally Unique AMF Identifier within the "guami" attribute.

• 5G to WiFi handover: When the UE handed over from the 5GS to EPC non-3GPP access, the SMF includes, if the "SCNN_CH" policy control request trigger is provisioned and met, the ePDG identification within the "anGwAddr" attribute included in the "servNfId" attribute.

The Dynamic PCC Rules Enforcement feature complies with the 3GPP TS 29.512, Release 15.2.0.

The Dynamic PCC Rules Enforcement feature has the following limitations:

• SMF supports only the following combination of operations:

  • Creation of new PCC Rule with new QoS descriptor to create new QoS Flow

  • Addition of new PCC Rule to an existing QoS Flow

  • Removal of PCC rule

  • Updating of GBR/MBR parameters associated with the rule

  • Session AMBR Changes

  • Session AMBR Changes and PCC Rules cannot be combined in the same update operation

• The current implementation supports only QoS Descriptors with standard 5QI and ignores the non-standard ones. If all the QoS Desc received are non-standard, then all are ignored and the default one created by SMF is used.

This section describes how to create an instance of a quality of service (QoS) profile.

configure 
   profile qos qos_profile_name 
   end 

NOTES:

• qos qos_profile_name : This command creates a quality of service profile and provides access to the QoS Profile Configuration mode to use the commands to configure the QoS parameters. See the qos-profile section of the Command Line Interface Reference for command information. qos_profile_name must be an alphanumeric string uniquely identifying the QoS profile.

This section describes how to configure the QoS parameters.

configure 
   profile qos qos_profile_name 
      ambr { ul uplink_ambr | dl downlink_ambr } 
      arp { preempt-cap preemption_capability |   
      preempt-vuln preemption_vulnerability |  
      priority-level priority_level } 
      max data-burst burst_volume 
      priority qos_priority 
      qi5 5qi_value 
      end 

NOTES:

• ambr { ul uplink_ambr | dl downlink_ambr } : Defines the Aggregate Maximum Bit Rate (AMBR) for the uplink (subscriber to network) and the downlink (network to subscriber) traffic.

• arp preempt-cap preemption_capability : Specifies the preemption capability flag. Options are:

  • MAY_PREEMPT: Bearer may be preempted

  • NOT_PREEMPT: Bearer cannot be preempted

• arp preempt-vuln preemption_vulnerability : Specifies the preemption vulnerability flag. Options are:

  • PREEMPTABLE: Bearer may be preempted

  • NOT_PREEMPTABLE: Bearer cannot be preempted

• arp priority-level priority_level : Defines the Allocation and Retention Priority (ARP) for the service data. The default value of priority_level is 8.

• max data-burst burst_volume : Defines the maximum data burst volume. burst_volume must be an integer value in the range of 1–4095.

• priority qos_priority : Specifies the 5QI priority level. qos_priority must be an integer value in the range of 1–127.

• qi5 5qi_value : Specifies the 5G QoS Identifier (5QI) for the authorized QoS parameters. 5qi_value must be an integer value in the range of 0–255.

This section describes how to configure the QoS profile in the existing DNN profile configuration.

configure 
   profile dnn dnn_profile_name 
      qos-profile qos_profile_name 
      end 

NOTES:

• qos-profile qos_profile_name : This command defines locally configured default QoS profile. This profile is configured under the existing DNN Profile Configuration. qos_profile_name must be the name of the configured QoS profile.

This section describes how to verify the Dynamic PCC Rules Enforcement feature configuration.

Use the following show command to verify the feature configuration details.

show full-configuration

The following is an example of this show command output.

show full-configuration 
profile dnn dnn1 
qos-profile qos1 
! 
profile qos qos1 
ambr ul 1024 
ambr dl 1024 
qi5 128 
arp priority-level 8 
arp preempt-cap NOT_PREEMPT 
arp preempt-vuln NOT_PREEMPTABLE 
priority 9 
max data-burst 2048 
exit 

This feature utilizes the functionalities provided by PDU Session Lifecycle feature.

This section describes the changes related to converged core refactoring in this chapter.

The host-pool CLI command in the ACS Rule Definitions mode is deprecated in 2021.01 and later releases.

Once the Active Charging Service configuration is done (including rulebase, associated ruledefs, and charging actions), SMF processes the configured values and derives PCC Rules, QoSData, and ChargingData from the configured values. The following principles are used to create these entities:

1. QoSData:

   1. Each configured charging action results in a QoSDesc creation.

   2. The flow-limit-bandwidth configured under charging action provides the GBR/MBR for the QoSData.

   3. The QCI and ARP configured in charging action constitute the 5QI and ARP of the QoSData. If no QCI and ARP are configured, the 5QI and ARP of the default QoS flow are associated with this QoSData.

2. ChargingData:

   1. The billing-action configuration under charging action determines whether offline charging is enabled in the created ChargingData.

   2. The cca charging credit configuration under charging action determines whether online charging is enabled in the created ChargingData.

   3. The rating group and service ID of the ChargingData are provided by content-id and service-identifier configuration under charging action.

3. PCCRule:

   1. Each ruledef under a rulebase results in creation of a PCCRule.

   2. The packet-filter configured under charging action is used for the FlowInformation in the PCCRule.

   3. The QoSData and ChargingData associated with this ruledef in the rulebase configuration form the refQoS and refChg for this PCCRule.

All the created PCCRules, QoSData, and ChargingData are saved per rulebase.

1. During PDU session creation, PCF sends the rulebase name (value configured under upf-apn is selected if the PCF does not send it) as PCCRule with ID set to cbn# configured rulebase name. It may also send any predefined rule to be activated as another PCCRule with ID set to crn# configured ruledef name. All such PCC rules will have only the RuleId attribute present.

2. On receiving such a request, SMF selects the constructed PCCRules, QoSData, and ChargingData which correspond to the received rulebase and ruledef names, and uses these to create QoS flows in QoSModel.

3. On the N4 interface, the SMF sends the rulebase name in the CreatePDR IE in a Cisco Proprietary IW named "rulebase".

4. For all activated predefined rules, SMF sends one uplink and one downlink PDR containing the ruledef name in "Activate Predefined Rule" IE.

5. The UPF also has similar configuration for active charging service. From the rulebase name and ruledef names, it can create the corresponding QER and URR.

6. On N1 and N2 interfaces, the processing of the predefined and static rules are the same as that of dynamic rule.

7. For all static and activated predefined rules, QoSRules are sent on N1 interface if packet-filters were configured.

8. The GFBR and MFBR of a flow are computed using the GBR/MBR of the QoSData associated with all static and activated predefined rules at any point of time and the same is sent on N2 interface in an AuthorisedQoSDescription IE on N1 interface.

1. During PDU session modification, PCF sends the rulebase name as PCCRule with ID set to cbn#configured rulebase name. In case of predefined rule PCF can activate new rule crn#configured ruledef name or delete the existing rule (crn#"nil"). All such PCC Rules will have only the RuleId attribute present.

2. On receiving new rule addition request, SMF selects the constructed PCCRules, QoSData and ChargingData which correspond to the received rulebase and ruledef names, and uses these to create QoS flows in QoSModel.

3. On receiving an existing rule deletion request, if the SMF received a ruledef name with nil value or a rulebase name different from the existing one, the SMF deletes the QoS flows which correspond to previous rulebase name or ruledef in QoSModel.

4. On N4 interface, SMF sends the new rulebase name in the CreatePDR IE in a Cisco Proprietary IW named "rulebase" and RemovePDR with PDR ID which correspond to the old rulebase name.

5. For all activated predefined rules, SMF sends one uplink and one downlink PDR containing the ruledef name in "Activate Predefined Rule" IE.

6. For all deactivated predefined rules, SMF sends RemovePDR with PDR ID which corresponds to the predefined rule.

7. The UPF also has similar configuration for active charging service. From the rulebase name and ruledef names, it can create or delete the corresponding QER and URR.

8. On N1 and N2 interfaces, the processing of the predefined and static rules are the same as that of dynamic rule.

9. For all static and activated/deactivated predefined rules, QoSRules are sent on N1 interface if packet-filters were configured.

10. The GFBR and MFBR of a flow are computed using the GBR/MBR of the QoSData associated with all static and activated/deactivated predefined rules at any point of time and the same is sent on N2 interface in an AuthorisedQoSDescription IE on N1 interface.

The Dynamic PCC Rules Enforcement feature has the following limitations:

• SMF supports only the following combination of operations:

  • Creation of new PCC Rule with new QoS descriptor to create new QoS Flow

  • Addition of new PCC Rule to an existing QoS Flow

  • Removal of PCC rule

  • Updating of GBR/MBR parameters associated with the rule

  • Session AMBR Changes

  • Session AMBR Changes and PCC Rules cannot be combined in the same update operation

• The current implementation supports only QoS Descriptors with standard 5QI and ignores the non-standard ones. If all the QoS Desc received are non-standard, then all are ignored and the default one created by SMF is used.

ACS provides flexible, differentiated, and detailed billing to subscribers through Layer 3 through Layer 7 packet inspection and the ability to integrate with back-end billing mediation systems.

Important

In this release, only one active charging service can be configured per system.

This section describes how to configure ACS.

configure 
   active-charging service service_name 
   end 

NOTES:

• active-charging service service_name : Specifies the name of an Active Charging Service. service_name must be an alphanumeric string of 1 to 15 characters.

• If the named ACS does not exist, it is created, and the CLI mode changes to the ACS Configuration Mode wherein the service can be configured. If the named ACS already exists, the CLI mode changes to the ACS Configuration Mode. The ACS Configuration mode is used to manage ACS or enhanced charging service (ECS) configurations.

This section describes how to configure charging action. The charging action represents actions to be taken when a configured rule is matched. Actions could range from generating an accounting record (for example, an EDR) to dropping the IP packet, and so on. The charging action will also determine the metering principle—whether to count retransmitted packets and which protocol field to use for billing (L3, L4, L7, and so on).

The charging action configuration is used to define the QoS and charging related parameters associated with ruledefs.

configure 
    active-charging service service_name 
       charging-action charging_action 
          allocation-retention-priority priority  [ pci pci_value 
          | pvi pvi_value billing-action egcdr cca 
          charging credit [ rating-group coupon_ id  
          ] [ preemptively-request ] 
          content-id content_id 
          flow action { discard [ downlink | uplink ] | redirect-url  
          redirect_url | terminate-flow } 
          flow limit-for-bandwidth { { direction { downlink | uplink }  
          peak-data-rate bps peak-burst-size bytes violate-action  
          { discard | lower-ip-precedence } [ committed-data-rate  
          bps committed-burst-size bytes 
          [ exceed-action { discard | lower-ip-precedence  
          } ] ] } | { id id } } 
          nexthop-forwarding-address ipv4_address/ipv6_address 
          qos-class-identifier qos_class_identifier 
          service-identifier service_id 
          tft packet-filter packet_filter_name 
          tft-notify-ue 
          tos { af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32  
          | af33 | af41 | af42 | af43 | be | ef | lower-bits tos_value  
          } [ downlink | uplink ] 
          end 

NOTES:

• charging-action charging_action_name : Specifies the name of a charging action. charging_action_name must be an alphanumeric string of 1 to 63 characters and can contain punctuation characters. Each charging action must have a unique name.

• If the named charging action does not exist, it is created, and the CLI mode changes to the ACS Charging Action Configuration Mode wherein the charging action can be configured.

• If the named charging action already exists, the CLI mode changes to the ACS Charging Action Configuration Mode for that charging action.

• allocation-retention-priority priority [ pcipci_value | pvi pvi_value : Configures the Allocation Retention Priority (ARP). priority must be an integer value in the range of 1-15.

  • pci pci_value : Specifies the Preemption Capability Indication (PCI) value. The options are:

    • MAY_PREEMPT - Flow can be preempted. This is the default value.

    • NOT_PREEMPT - Flow cannot be preempted

  • pvi pvi_value: Specifies the Preemption Vulnerability Indication (PVI) value. The options are:

    • NOT_PREEMPTABLE - Flow cannot be preempted. This is the default value.

    • PREEMPTABLE - Flow can be preempted

• billing-action : Configures the billing action for packets that match specific rule definitions.

• cca charging credit : Enables or disables Credit Control Application (CCA) and configures the RADIUS/Diameter prepaid charging behavior.

• content-id: Configures the rating group.

• flow action: Specifies the action to take on packets that match rule definitions.

• flow limit-for-bandwidth: Configures the QoS parameters such as MBR, GBR, and so on.

  • peakdatarate(MBR): Default is 3000 bps

  • peakburstsize: Default is 3000 bytes

  • committedDataRate(GBR): Default is 144000 bps

  • committedBurstSize: Default is 3000 bytes

• nexthop-forwarding-address ipv4_address/ipv6_address : Configures the nexthop forwarding address.

• qos-class-identifier qos_class_identifier : Configures the QoS Class Identifier (QCI) for a charging action. qos_class_identifier must be an integer value in the range of 1-9 or from 128-254 (Operator specific).

• service_identifier service_id : Configures the service identifier to use in generated billing records.service_id must be an integer value in the range of 1-2147483647.

• tft packet-filter packet_filter_name : Specifies the packet filter to add or remove from the current charging action. packet_filter_name must be the name of a packet filter, and must be an alphanumeric string of 1 to 63 characters.

• tft-notify-ue : Control the TFT updates towards the UE based on certain trigger conditions.

• tos : Configures the Type of Service (ToS) octets.

This section describes the commands that are used to configure packet filter.

configure 
   active-charging service service_name 
      packet-filter packet_filter_name 
         direction { bi-directional | downlink | uplink } 
         ip local-port { = port_number | range start_port_number to 
         end_port_number } 
         ip protocol = protocol_number 
         ip remote-port { = port_number | range start_port_number to  
         end_port_number } 
         ip tos-traffic-class = { type-of-service | traffic class } 
         mask { = mask-value} 
         priority priority 
         end 

NOTES:

• packet-filter packet_filter_name : Configures the packet filters to be sent to UE. packet_filter_name must be the name of the packet filter, and must be an alphanumeric string of 1 to 15 characters.

• direction { bi-directional | downlink | uplink } : Configures the direction in which the packet filter has to be applied. The default value is bi-directional.

• ip local-port : Configures the IP 5-tuple local port(s) for the current packet filter.

• ip protocol : Configures the IP protocol(s) for the current packet filter.

• ip remote-address : Configures the IP remote address(es) for the current packet filter.

• ip remote-port : Configures the IP remote port(s) for the current packet filter.

• ip tos-traffic-class : Configures Type of Service (TOS)/Traffic class under charging action in the Packet filter mode.

• priority priority : Configures the current packet filter's priority.

A ruledef represents a set of matching conditions across multiple L3 – L7 protocol based on protocol fields and state information. Each ruledef can be used across multiple rulebases within the active charging service.

This section describes how to create, configure, or delete ACS rule definitions.

configure 
   active-charging service service_name 
      ruledef ruledef_name 
         ip any-match [ = | != ] [ TRUE | FALSE ] 
         ip dst-address { operator { { ipv4_address | ipv6_address 
         } | { ipv4_address/mask | ipv6_address/mask} | 
         address-group ipv6_address } | { !range | range }  

         rule-application { charging | post-processing | routing } 
         end 

NOTES:

• ruledef ruledef_name : Specifies the ruledef to add, configure, or delete. ruledef_name must be the name of an ACS ruledef, and must be an alphanumeric string of 1 to 63 characters, and can contain punctuation characters. Each ruledef must have a unique name. Host pool, port map, IMSI pool, and firewall, routing, and charging ruledefs must have unique names.

• If the named ruledef does not exist, it is created, and the CLI mode changes to the ACS Ruledef Configuration Mode wherein the ruledef can be configured.

• If the named ruledef already exists, the CLI mode changes to the ACS Ruledef Configuration Mode for that ruledef. The ACS Ruledef Configuration Mode is used to create and manage rule expressions in individual rule definitions (ruledefs).

• ip any-match [= | !=] [TRUE | FALSE]: This command defines the rule expressions to match IPv4/IPv6 packets. The operator and condition in the command specifies the following:

  • operator

    • !=: Does not equal

    • < =: Equals

  • condition

    • FALSE

    • TRUE

• ip dst-address { operator { { ipv4_address | ipv6_address } | { ipv4_address/mask |ipv6_address/mask } | address-group ipv6_address } | { !range | range } host-pool host_pool_name } : This command allows defining rule expressions to match IP destination address field within IP headers.

  • ipv4_address | ipv6_address : Specifies the IP address of the destination node for outgoing traffic. ipv4_address | ipv6_address must be an IP address in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation.

  • ipv4_address/mask | ipv6_address/mask : Specifies the IP address of the destination node for outgoing traffic. ipv4_address/mask | ipv6_address/mask must be an IP address in IPv4 dotted-decimal or IPv6 colon-separated-hexadecimal notation with subnet mask bit. The mask bit is a numeric value which corresponds to the number of bits in the subnet mask.

  • address-group ipv6_address : Specifies a group of IPv6 addresses configured with wildcard input and/or specialized range input. Multiple wildcard characters can be accepted as input and only one 2 byte range input will be accepted. Both wildcard character input and 2-byte range input can be configured together within a given IPv6 address.

  • The operator in the command specifies the following:

    • !=: Does not equal

    • <: Lesser than or equals

    • =: Equals

    • >=: Greater than or equals

• multi-line-or all-lines : This command allows a single ruledef to specify multiple URL expressions. When a ruledef is evaluated, if the multi-line-or all-lines command is configured, the logical OR operator is applied to all the rule expressions in the ruledef to decide if the ruledef matches or not. If the multi-line-or all-lines command is not configured, the logical AND operator is applied to all the rule expressions.

• rule-application { charging | post-processing | routing } : This command specifies the rule application for a rule definition.

  • charging : Specifies that the current ruledef is for charging purposes.

  • post-processing : Specifies that the current ruledef is for post-processing purposes. This enables processing of packets even if the rule matching for them has been disabled.

  • routing : Specifies that the current ruledef is for routing purposes. Up to 256 rule definitions can be defined for routing in an Active Charging Service. Default: Disabled.

A group-of-ruledefs can contain optimizable ruledefs. Ruledef group optimization depends on the optimization ability of ruledefs in the group-of-ruledefs, and the optimization configuration of the group in a rulebase.

Upon adding a new ruledef, the following checks occur:

• Determines if the new ruledef is part of any existing group of ruledefs

• Identifies if the new ruledef requires optimization

Use the following configuration to combine a set of ruledefs together to apply the same charging action on them.

configure 
   active-charging service service_name 
      group-of-ruledefs ruledef_group_name 
         add-ruledef priority ruledef_priority ruledef ruledef_name 
         end 

NOTES:

• group-of-ruledefs ruledef_group_name : Specifies the ruledef group name to add, configure, or delete. This command allows up to a maximum of 128 group of ruledef configurations.

• add-ruledef: This command allows you to add or remove ruledefs from a group-of-ruledefs. This command allows up to a maximum of 128 ruledef configurations.

• priority: Specifies the priority of the ruledef in the current group of ruledefs. ruledef_priority is an integer from 1 through 10000.

• ruledef ruledef_name : Specifies name of the ruledef to add to the current group-of-ruledefs. ruledef_name must be the name of an ACS ruledef, and must be an alphanumeric string of 1 to 63 characters.

Rulebase and predefined rule prefix configuration is mandatory for static rule installation from PCF. The SMF supports the predefined rule installation with prefix and without prefix. The SMF also supports the group-of-ruledef installation for both predefined and static rules.

Use the following configuration to configure the rulebase prefix and predefined rule prefix.

configure 
   profile network-element pcf pcf_service_name 
      predefined-rule-prefix predef_rule_prefix 
      rulebase-prefix rulebase_prefix 
      end 

NOTES:

• predefined-rule-prefix predef_rule_prefix : Specifies the predefined rule prefix to be added. For example, the prefix for predefined rule is cbr .

• This is an optional configuration for the predefined rule. When there is no prefix defined within the PCF network element profile, the predefined rule application behaves as defined in the 3GPP TS 29.244 specification.

• rulebase-prefix rulebase_prefix : Specifies the rulebase prefix to be added. For example, the prefix for rulebase is rbn . This is a mandatory configuration for the static rule.

This section describes how to enable and configure an ACS rulebase to be used for subscribers who use the configured APN.

configure 
   apn apn_name 
      active-charging rulebase rulebase_name 
      end 

NOTES:

• active-charging rulebase rulebase_name : Specifies the name of the ACS rulebase. rulebase_name must be an alphanumeric string of 1 to 63 characters.

This section describes how to configure the Usage Reporting Rules (URR) ID for the rating and service groups.

configure 
   active-charging service service_name 
      urr-list list_name 
         rating-group rating_id service-identifier service_id_value  
          urr-id urr_id_value 
          end 

NOTES:

• urr-list list_name : Specifies the name of the URR list, and must be an alphanumeric string of 1 to 63 characters.

• rating-group rating_id : Specifies the rating ID used in charging. rating_id must be an integer value in the range of 0-2147483647.

• service-identifier service_id_value : Configures the service identifier value. service_id_value must be an integer value in the range of 0-2147483647.

• urr-id urr_id_value : Configures URR identifier for rating/service group. urr_id_value must be an integer value in the range of 1-8388607.

• The URR ID configuration is per rating group and service ID. For different rating group and service ID combinations, use the URR ID configuration command as many times as needed.

This section describes the commands that are used to configure GTPP group.

configure 
   gtpp group group_name 
      gtpp trigger { time-limit | volume-limit } 
      end 

NOTES:

• gtpp group group_name : Specifies the GTPP group name. group_name must be an alphanumeric string of 1 to 63 characters.

• gtpp trigger { time-limit | volume-limit } : Configures triggers for CDR.

  • time-limit : Enables time-limit trigger for the CDR.

  • volume-limit : Enables volume-limit trigger for the CDR.

This section describes how to create APN templates. This APN configuration represents the access point configuration in the UPF and further facilitates configuring a rulebase name within.

configure 
   apn apn_name 
   end 

NOTES:

• apn apn_name : Specifies a name for the APN template as an alphanumeric string of 1 to 62 characters and is case insensitive.

This section describes how to associate the GTTP group with the configured APN.

configure 
   apn apn_name 
      gtpp group group_name 
      end 

NOTES:

• gtpp group group_name : Associates the defined GTPP group with the already configured APN.

This section describes how to create, configure, or delete an ACS rulebase. A rulebase is a collection of protocol rules to match a flow and associated actions to be taken for matching flow. The default rulebase is used when a subscriber/APN is not configured with a specific rulebase to use.

Rulebase configuration is the one that combines all the specified configurations together to construct the static and predefined PCC rules.

configure 
   active-charging service service_name 
      rulebase rulebase_name 
         action priority action_priority { [ dynamic-only ]  
         | static-and-dynamic | timedef timedef_name ]  
         { group-of-ruledefs ruledefs_group_name | 
         ruledef ruledef_name } charging-action charging_action_name 
         [ monitoring-key monitoring_key ] [ description description ] } 
         cca quota { holding-time holding_time content-id content_id  
         | retry-time retry_time [ max-retries retries ] } 
         cca quota time-duration algorithm { consumed-time seconds  
         [ plus-idle ] | continuous-time-periods seconds | 
         parking-meter seconds} [ content-id content_id]    
         credit-control-group cc_group_name 
         dynamic-rule order { always-first | first-if-tied } 
         egcdr threshold { interval interval  
         [ regardless-of-other-triggers ] | volume { downlink | total | 
         uplink } bytes } 
         route priority route_priority ruledef ruledef_name  
         analyzer { dns | file-transfer | ftp-control | ftp-data | h323 
         | http | imap | mipv6 | mms | pop3 | pptp | radius | rtcp | rtp 
         | rtsp | sdp | secure-http | sip [ advanced | basic-and-advanced 
         ] 
         | smtp | tftp | wsp-connection-less | wsp-connection-oriented } 
         [ description description ] 
         tcp check-window-size 
         tcp mss tcp_mss { add-if-not-present | limit-if-present } 
         tcp packets-out-of-order { timeout timeout_duration| 
         transmit [ after-reordering | immediately ] } 
         end 

NOTES:

• rulebase rulebase_name : Specifies the name of the ACS rulebase. rulebase_name must be an alphanumeric string of 1 to 63 characters.

• action priority action_priority { [ dynamic-only ] | static-and-dynamic | timedef timedef_name ] { group-of-ruledefs ruledefs_group_name | ruledef ruledef_name } charging-action charging_action_name [ monitoring-key monitoring_key ] [ description description ] } : Configures the priority order in which ruledefs are matched and the associated charging action.

  • priority must be an integer value in the range of 1-65535.

  • monitoring_key must be an integer value in the range of 100000-4000000000.

  Use the no action priority action_priority command to remove the configured ruledef, group-of-ruledefs, and charging action.

  Important

  Currently, the SMF does not support individual removal of ruledef, group-of-ruledefs, and charging action.

• cca quota { holding-time holding_time content-id content_id | retry-time retry_time [ max-retries retries ] } : Configures the quota for the online charging.

  • holding_time : must be an integer value in the range of 1-4000000000

  • content_id : must be an integer value in the range of 1-2147483647

  • retry_time : must be an integer value in the range of 0-86400

  • retries : must be an integer value in the range of 1-65535

• cca quota time-duration algorithm { consumed-time seconds [ plus-idle ] | continuous-time-periods seconds | parking-meter seconds } [ content-id content_id ]

  • consumed-time: must be an integer value in the range of 1-4294967295

  • content-id: must be an integer value in the range of 1-2147483647

  • continuous-time-periods: must be an integer value in the range of 1-4294967295

  • parking-meter: must be an integer value in the range of 1-4294967295

• credit-control-group cc_group_name : Configures the online charging parameters used by this rulebase. cc_group_name must be an alphanumeric string of 1 to 63 characters.

• dynamic-rule order : Configures the order of dynamic rule matching vs the static rules in a rulebase.

• egcdr threshold { interval interval [ regardless-of-other-triggers ] | volume { downlink | total | uplink } bytes } : Configures the threshold for offline charging.

  • interval : must be an integer value in the range of 60-40000000.

  • downlink : must be an integer value in the range of 100000-4000000000. Default: 4000000000.

  • uplink : must be an integer value in the range of 100000-4000000000. Default: 4000000000.

  • total : must be an integer value in the range of 100000-4000000000.

• route priority route_priority ruledef ruledef_name analyzer { dns | file-transfer | ftp-control | ftp-data | h323 | http | imap | mipv6 | mms | pop3 | pptp | radius | rtcp | rtp | rtsp | sdp | secure-http | sip [ advanced | basic-and-advanced ] | smtp | tftp | wsp-connection-less | wsp-connection-oriented } [ description description ] : This command is used only on UPF.

  • route_priority must be an integer value in the range of 0-65535.

  • ruledef_name must be an alphanumeric string of 1 to 63 characters.

• tcp check-window-size : This command is used only on UPF.

• tcp mss tcp_mss : This command is used only on UPF. tcp_mss must be an integer value in the range of 496-65535.

• tcp packets-out-of-order { timeout timeout_duration | transmit [ after-reordering | immediately ] } : This command is used only on UPF.

  • timeout_duration must be an integer value in the range of 100-30000. Default value is 5000.

This section describes how to configure the UPF APN profile in the existing DNN Profile Configuration.

configure 
   profile dnn dnn_profile_name 
      upf apn apn_name 
      end 

NOTES:

• upf apn apn_name : This command enables UPF APN profile configuration. This profile is configured under the existing DNN profile configuration. apn_name must be the name of the APN template, and must be an alphanumeric string of 1 to 62 characters.

This section describes how to configure the QoS parameters.

configure 
   profile qos qos_profile_name 
      ambr { ul uplink_ambr | dl downlink_ambr } 
      arp { preempt-cap preemption_capability |   
      preempt-vuln preemption_vulnerability |  
      priority-level priority_level } 
      max data-burst burst_volume 
      priority qos_priority 
      qi5 5qi_value 
      end 

NOTES:

• ambr { ul uplink_ambr | dl downlink_ambr } : Defines the Aggregate Maximum Bit Rate (AMBR) for the uplink (subscriber to network) and the downlink (network to subscriber) traffic.

• arp preempt-cap preemption_capability : Specifies the preemption capability flag. Options are:

  • MAY_PREEMPT: Bearer may be preempted

  • NOT_PREEMPT: Bearer cannot be preempted

• arp preempt-vuln preemption_vulnerability : Specifies the preemption vulnerability flag. Options are:

  • PREEMPTABLE: Bearer may be preempted

  • NOT_PREEMPTABLE: Bearer cannot be preempted

• arp priority-level priority_level : Defines the Allocation and Retention Priority (ARP) for the service data. The default value of priority_level is 8.

• max data-burst burst_volume : Defines the maximum data burst volume. burst_volume must be an integer value in the range of 1–4095.

• priority qos_priority : Specifies the 5QI priority level. qos_priority must be an integer value in the range of 1–127.

• qi5 5qi_value : Specifies the 5G QoS Identifier (5QI) for the authorized QoS parameters. 5qi_value must be an integer value in the range of 0–255.

This section describes how to verify the Static PCC Rules Support configuration.

Use the following show command to verify the feature configuration details.

show full-configuration

The following is an example of this show command output.

active-charging service acs 
charging-action ca1 
  arp priority-level 15 preempt-cap MAY_PREEMPT preempt-vuln PREEMPTABLE 
  cca charging credit preemptively-request 
  content-id 320001 
  flow limit-for-bandwidth direction uplink peak-data-rate 1000000 peak-burst-size 1000000 violate-action discard committedDataRate 2000000 committed-burst-size 2000000 exceed-action lower-ip-precedence 
  nexthop-forwarding-address fa00:965a:c263:25::16/128 
  qos-class-identifier 9 
  service-identifier 32000 
  tft packet-filter pf1 
  tft-notify-ue 
  tos af11 downlink 
rulebase rb1 
  cca quota time-duration algorithm parking-meter 1000 content-id 18000 
  credit-control-group cg1 
  dynamic-rule order first-if-tied 
  egcdr threshold volume total 400000 
  tcp packets-out-of-order transmit immediately 
  action priority 95 timedef ruledef rd6 charging-action ca6 description ruledef 
  action priority 96 ruledef rd3 charging-action ca5 
  action priority 97 group-of-ruledefs grd3 charging-action ca4 monitoring-key 200000 
  action priority 98 static-and-dynamic group-of-ruledefs grd2 charging-action ca2 
  action priority 99 dynamic-only ruledef rd1 charging-action ca1 monitoring-key 100000 
  action priority 100 dynamic-only group-of-ruledefs grd1 charging-action ca1 monitoring-key 100000 description gruledefs 
  route priority 1 ruledef rd1 analyzer dns description dns 
exit 
packet-filter pk1 
  direction uplink 
  ip local-port = 23 
  ip protocol = 23 
  ip remote-address = 10.10.10.0/24 
  ip remote-port = 23 
  ip tos-traffic-class = 23 mask = 10 
  priority  4 
exit 
ruledef prepaidBgl 
  multi-line-or all-lines 
  rule-application charging 
  ip any-match = TRUE 
  ip server-ip-address range host-pool 12 
  ip dst-address = 10.10.10.10 
exit 
urr-list urrlocal 
  rating-group 1 service-identifier 1 urr-id 2 
  rating-group 1 service-identifier 3 urr-id 2 
exit 
exit 

Use the following show command to verify the group-of-ruledefs configuration details.

show running-config

The following is an example of this show command output.

show running-config 
profile network-element pcf pcf1 
rulebase-prefix   rbn 
predefined-rule-prefix cbr 
! 
active-charging service acs1 
group-of-ruledefs IPV6-whtlst-https_2300 
  add-ruledef priority 1 ruledef IPV6-whtlst-https_2300_01 
  add-ruledef priority 2 ruledef IPV6-whtlst-https_2300_02 
  add-ruledef priority 3 ruledef IPV6-whtlst-https_2300_03 
  add-ruledef priority 4 ruledef IPV6-whtlst-https_2300_04 
  add-ruledef priority 5 ruledef IPV6-whtlst-https_2300_05 
  add-ruledef priority 6 ruledef IPV6-whtlst-https_2300_06 
  add-ruledef priority 7 ruledef IPV6-whtlst-https_2300_07 
  add-ruledef priority 8 ruledef IPV6-whtlst-https_2300_08 
  add-ruledef priority 9 ruledef IPV6-whtlst-https_2300_09 
  add-ruledef priority 10 ruledef IPV6-whtlst-https_2300_10 
  add-ruledef priority 11 ruledef IPV6-2dns-whtlst-https_2300_01 
  add-ruledef priority 12 ruledef IPV6-2dns-whtlst-https_2300_02 
  add-ruledef priority 13 ruledef IPV6-2dns-whtlst-https_2300_03 
exit 
group-of-ruledefs rdg1 
  add-ruledef priority 10 ruledef rd2 
  add-ruledef priority 12 ruledef rd1 
exit 
exit 

This section lists the differences between the predefined and static rules.

• Predefined rule is identified by the dynamic-only keyword in the action priority associated with a ruledef under rulebase configuration.

• Predefined rules are not activated automatically but are enabled or disabled by PCF on a per rule basis. The PCF sends a PCC rule with the ruledef name alone or ruledef and rulebase names together as the rule ID to activate the predefined rule and sends the PCC rule map with null entry for the ruledef previously activated to deactivate a predefined rule.

• The QoS binding and modelling is not done for predefined rules at the time of configuration unlike the static rule. Instead during PDU session activation/modification the ECS configuration of activated ruledefs are considered to create or change the QoS model applicable for the session.

• On N4 interface, one PDR and corresponding FAR per ruledef activated by the PCF is sent to the UPF with ruledef name in the Activate predefined Rule IE and rulebase name is sent in Rulebase IE in default PDR. On rule removal, the corresponding PDR is removed.

Note	The PCF sends the predefined rules, and activates these rules only if the UPF APN is configured with "rulebase" name. Otherwise, the PCF must send the rule name along with the "rulebase" name.

All three static, predefined, and dynamic rules can coexist for a session. In such a case:

• Pre-constructed QoS model is prepared only for static rules. During PDU session activation/modification, any dynamic and predefined rules are evaluated to modify the QoS model and accordingly modifications are done on N1, N2, and N4 interfaces.

• If the rating-group and service ID for a dynamic rule are the same as that of a configured predefined and static rule, then the URR ID for the static and predefined rule is retained even for the dynamic rule.

Use the following show command to verify the bandwidth ID configuration.

show config-error 

This show command helps in identifying any invalid configurations such as the configured bandwidth ID being removed but still defined in the charging action. For such invalid configurations, this show command displays appropriate errors as shown in the following example output:

show-config-error 

ERROR COMPONENT      ERROR DESCRIPTION
--------------------------------------------------------------------------------------------------
RuleBase        Default bandwidth policy does not exist in rulebase <rba1> for charging action <ca1> .Dropping ruleDef <rda1>
RuleBase        Default bandwidth policy does not exist in rulebase <rba6> for charging action <ca1>.Dropping ruleDef <rda60>
RuleBase        Default bandwidth policy does not exist in rulebase <rba6> for charging action <ca1>.Dropping ruleDef <rda61>
ChargingAction  Packet filter <pkt1234> configured for charging action <ca4> associated with rulebase <rb1> does not exist
BandWidthPolicy Uplink peak data rate less than commited data rate in charging action <ca6>Dropping ruleDef <rd6>

 

The SMF performs UPF selection from a list of all UPFs having an active association based on certain selection criteria including the query parameters. These parameters consist of DNN, pdn-type-subscription, pdn-type-session, priority, load, and Dual Connectivity with New Radio (DCNR) (only for EPS).

The 5GS and EPS core networks apply the selection mechanism to select a UPF node during the creation of a subscriber session.

The UPF selection can be based on the load of the UPFs. The load-based UPF selection distributes calls among active UPFs associated with SMF. 3GPP specifies Load Control feature as optional feature over N4 reference points. This enables UPF to send its load information to CP functions.

To support load-based UPF selection, the SMF uses UPF-provided Load Control information in the following Packet Forwarding Control Protocol (PFCP) messages:

• Session Establishment Response

• Session Modification Response

• Session Deletion Response

• Session Report Request

Load Control procedure details are mentioned in 3GPP TS 29.244 v14.0.0 Release 14, section 6.2.3 and SMF adheres to the CP functionality.

The UPF initiates an N4 Association Setup request to set up an association with SMF.

The following is a high-level summary of how SMF selects the UPF node for the core network:

• The SMF selects the UPF node for EPS and 5GS sessions based on the following parameters:

  • DNN

  • DCNR (only for EPS calls)

  • pdn-type-subscription

  • pdn-type-session

• The SMF/PGW-C enables you to define the UPF selection criteria which it uses to query the appropriate node.

• If multiple UPFs match the SMF's selection criteria, then SMF selects the active UPFs and sorts them based on their priority and load information. The SMF then attempts to access the UPF one by one until the N4 Session Establishment is successful.

• The SMF stores the load information provided by UPF and uses it in selecting the UPF for new sessions being established. The SMF selects the less loaded UPF among the candidate (DNN based) active UPFs.

• The SMF considers priority and capacity configured statically against each UPF. In cases where UPF does not send the load information statically, configured capacity is considered while selecting the UPFs.

This section describes how to configure the UPF Selection feature.

Configuring the UPF Selection feature involves the following steps:

1. Defining the UPF Group

2. Associating the UPF Group with UPF Network Element

3. Defining UPF Selection Query Parameters

4. Associating UPF Selection Query Parameters with DNN Profile

This section describes operations, administration, and maintenance information for this feature.

The SMF performs co-located UPF selection based on the SGW-U node name received in the Create Session Request (CSR) message.

The SMF performs the following steps to handle co-located UPF selection during PDN Session Establishment in 4G network.

1. Upon receiving the CSR request, the SMF fetches the "SGW-U node name" and compares with the FQDN defined in UPF configuration.

   The SMF skips the existing UPF selection logic and uses the UPF selected by SGW-C.

2. In the absence of the SGW-U node name, the SMF follows the existing UPF selection algorithm.

3. The SMF uses the existing selection logic if it is unable to derive the UPF from the configuration based on the SGW-U node name.

Use the following configuration to select the co-located UPF.

configure 
   profile network-element upf upf_name 
      node-id value 
      end 

NOTES:

• profile network-element upf upf_name : Specify a profile name for the UPF.

• node-id value : This keyword aids in configuring the node ID of UPF. The SMF compares this node name with SGW-U node name to select the co-located UPF. value is an alphanumeric string.

The SMF maintains the following statistics in support of this feature.

upf_selection_stats

Description: Displays the total number of times the same co-located UPF is selected by SMF.

Metrics-Type: Counter

Labels:

• upf_selection_type

• upf_fqdn

• preferred

• upf_not_associated

• upf_profile_not_found

• upf_not_active

• n4_failed

• pdu_session_type

• pdu_subscription_type

• snssai

Status:

• attempted

• failure

Reason: If the status is failure, the value can be one of the following:

• upf_not_associated

• upf_profile_not_found

• upf_not_active

• n4_failed

This section describes the changes related to converged core refactoring in this chapter.

• The namespace keyword is added to the show subscriber CLI command to display the output pertaining to the respective namespace.

• For Node Report and Session Report SMF-protocol statistics:

  • n4 prefix in the message names are removed

  • smf prefix in the statistic names are removed

  • interface_type label is added in the query expression

For proper handling of PFCP node report, the GTP-U peer address must include a non-unique secondary session key. The Common Data Layer (CDL) stores the peer address and the UPF IP address along with the session details. If the GTP-U peer address changes during idle to active transition procedure, N2 handover (HO), 5G to 4G HO, or 4G to 5G HO, the CDL database deletes the old key and adds the new one.

1. The UPF sends PFCP Node Report Request to the SMF along with the IP address of the failed GTP-U peer.

2. The SMF protocol checks the node ID, that is, the UPF IP address included in the request. If the node ID is not found or if the node ID is not in associated state, the SMF protocol sends a failure response.

3. If the node ID is found, the node manager queries the CDL for EPS session with the GTP-U peer IP address and node ID. The node manager sends bulk notification to the CDL to clear the corresponding sessions.

4. The CDL sends the notification to rest endpoint (REST-EP) pod to clear the sessions.

5. The REST-EP pod sends the subscriber clear notification to the SMF service based on the affinity. The SMF service clears the sessions on all interfaces.

The UPF sends PFCP session report along with GTER, SRIR, and SPTER to the SMF. If the session is found, the SMF sends a successful PFCP session report response. Then, the SMF triggers the PDU session release procedure and deletes the sessions on all interfaces.

For the newly supported messages (node report and session report), the SMF triggers the PDU session release procedure. If the PDU session release procedure collides with the HO procedure, the SMF does not abort the HO procedure as the GTP-U peer IP changes during the HO. To achieve this, the PDU release procedure involves comparing the GTP-U peer IP address received in release request with the one present in the PDU session. If the two addresses are different, then the SMF aborts the release procedure.

Important

The collision handling depends on the arrival time of the incoming HO message and clear subscriber command triggered by node report.

The SMF uses a retry timer to check and report any pending session deletions for a GTP-U peer. After the restart of SMF node manager, if any sessions are not deleted, then these sessions remain as is.

The UPF Node Report and Session Report Support feature complies with 3GPP TS 29.244, version 15.6.0.

This feature has the following limitations:

• If the CDL notifications are lost and the sessions are not cleared, the SMF node manager retries the bulk deletion operation only once after 10 minutes.

• If the node report request arrives and the system is in overload state, some CDL notifications are dropped. In this case, the SMF performs the session clean-up based on error indication report request from the UPF.

• The UPF currently sends only one Remote GTP-U peer in the Node Report request. So, the SMF can validate only one remote GTP-U peer.

An alarm is added to indicate that a GTP-U peer for a particular UPF has gone down. The alarm data includes GTP-U peer IP and UPF IP addresses.

Use the following commands to configure alert rules related to the UPF Node Report Request.

configure 
   alerts rules group alert_group_name 
   interval-seconds seconds 
   rule rule_name 
      expression promql_expression 
      severity severity_level 
      type alert-type 
      annotationannotation_name 
      value annotation_value 
      exit 
   exit 

• alerts rules : Specifies the Prometheus alerting rules.

• group alert_group_name : Specifies the Prometheus alerting rule group. One alert group can have multiple lists of rules. alert-group-name is the name of the alert group. The alert-group-name must be a string in the range of 0–64 characters.

• interval-seconds seconds : Specifies the evaluation interval of the rule group in seconds.

• rule rule_name : Specifies the alerting rule definition. rule_name is the name of the rule.

The following is a sample configuration.

configure 
   alerts rules group NodeReportGTPURemotePeer 
   interval-seconds 300 
   rule NodeReportGTPURemotePeerDown 
      expression smf_protocol_udp_res_msg_total{message_name=\"n4_node_report_req\", message_direction= \“inbound\”, status=\“accepted\”}” 
      severity major 
      type "Communications Alarm" 
      annotation summary 
      value “This alert is fired when the UPF Sends Node Report Request to SMF” 
      exit 
   exit 

Use the show subscriber all command to view the configuration related to GTP-U peer IP address.

The following is a sample output.

[unknown] smf# show subscriber all nf-service smf
subscriber-details
{
  "subResponses": [
    [
      "supi:imsi-123456789012345",
      "gpsi:msisdn-223310101010101",
      "pei:imei-123456786666660",
      "psid:5",
      "dnn:intershat",
      "emergency:false",
      "rat:e-utran",
      "access:3gpp access",
      "connectivity:4g",
      "udm-sdm:10.84.17.111",
      "pcfGroupId:PCF-dnn=;",
      "policy:2",
      "pcf:10.84.17.111",
      "upf:10.84.17.111",
      "upfEpKey:10.84.17.111:10.84.17.112",
      "ipv4-addr:poolv4/12.0.0.1",
      "ipv4-pool:poolv4",
      "ipv4-range:poolv4/12.0.0.1",
      "ipv4-startrange:poolv4/12.0.0.1",
      "gtp-peer:10.84.17.112",
      "peerGtpuEpKey:10.84.17.111:10.84.17.111",
      "namespace:smf"
    ]
  ]
}
 

Use the show subscriber count peerGtpuEpKey command to view the number of sessions associated with the specified GTP-U peer and the UPF node.

Important

Use the show subscriber count peerGtpuEpKey command carefully and sensibly as it might impact the system performance.

The following is a sample output of show subscriber count peerGtpuEpKey command.

smf# show subscriber count peerGtpuEpKey 30.30.30.63:50.50.0.58
  subscriber-details
  {
    "sessionCount": 12568
  }
 

The SMF maintains the following statistics to track the total number of attempted, successful, and failed node-level and session-level requests.

• SMF_SERVICE_STATS for the following procedure types:

  • upf_node_report_pdu_sess_rel

    attempted: Total number of attempted PDU session release requests triggered due to the node report.

    successful: Total number of successful PDU session release requests triggered due to the node report.

    failure: Total number of failed PDU session release requests triggered due to the node report.

  • upf_sess_report_gter_pdu_sess_rel

    attempted: Total number of attempted PDU session release requests triggered due to the session report “GTER”.

    successful: Total number of successful PDU session release requests triggered due to the session report “GTER”.

    failure: Total number of failed PDU session release requests triggered due to the session report “GTER”.

• SMF_PROTOCOL_UDP_REQ_MSG_TOTAL for the following message types:

  • n4_node_report_req

    attempted: Total number of attempted N4 requests triggered due to the node report.

    successful: Total number of successful N4 requests triggered due to the node report.

    failure: Total number of failed N4 requests triggered due to the node report.

  • n4_session_report_req

    attempted: Total number of attempted N4 requests triggered due to the session report.

    successful: Total number of successful N4 requests triggered due to the session report.

    failure: Total number of failed N4 requests triggered due to the session report.

• SMF_PROTOCOL_UDP_RES_MSG_TOTAL for the following message types:

  • n4_node_report_res

    attempted: Total number of attempted N4 responses triggered due to the node report.

    successful: Total number of successful N4 responses triggered due to the node report.

    failure: Total number of failed N4 responses due to the node report.

  • n4_session_report_res

    attempted: Total number of attempted N4 responses triggered due to the session report.

    successful: Total number of successful N4 responses triggered due to the session report.

    failure: Total number of failed N4 responses due to the session report.

• SMF_DISCONNECT_STATS triggered for the following disconnect reasons:

  gtpu_peer_path_failure : This statistic is triggered when the session is deleted due to the node report.

  upf_sess_report_gter_pdu_sess_rel: This statistic is triggered when the session is deleted due to the session report.

The following is an example of the statistics:

Node Report SMF-service stats:

smf_service_stats{app_name="SMF",cluster="Local",data_center="DC",dnn="intershat",
emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_node_report_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="attempted",up_state=""} 

smf_service_stats{app_name="SMF",cluster="Local",data_center="DC",dnn="intershat",
emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_node_report_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="success",up_state=""} 1
 

Session Report SMF-service stats:

smf_service_stats{always_on="",app_name="smf",cluster="smf",data_center="unknown",
dcnr="",dnn="intershat",emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_sess_report_gter_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="attempted",up_state=""} 1 

smf_service_stats{always_on="",app_name="smf",cluster="smf",data_center="unknown",
dcnr="",dnn="intershat",emergency_call="false",instance_id="0",pdu_type="ipv4",
procedure_type="upf_sess_report_gter_pdu_sess_rel",qos_5qi="",rat_type="NR",
reason="",service_name="smf-service",status="success",up_state=""} 1 

Node Report SMF-protocol stats:

smf_proto_udp_req_msg_total{app_name="smf",cluster="smf",data_center="unknown",
instance_id="0",message_direction="inbound",message_name="n4_node_report_req",
msgpriority="",service_name="smf-protocol",status="accepted",
transport_type="origin"} 15 

smf_proto_udp_res_msg_total{app_name="smf",cause="1",cluster="smf",
data_center="unknown",instance_id="0",message_direction="outbound",
message_name="n4_node_report_res",msgpriority="",service_name="smf-protocol",
status="accepted",transport_type="origin"} 15 

Session Report SMF-protocol stats:

smf_proto_udp_req_msg_total{app_name="smf",cluster="smf",data_center="unknown",
instance_id="1",message_direction="inbound",message_name="n4_session_report_req",
msgpriority="",service_name="smf-protocol",status="accepted",
transport_type="origin"} 43 

smf_proto_udp_res_msg_total{app_name="smf",cause="1",cluster="smf",
data_center="unknown",instance_id="1",message_direction="outbound",
message_name="n4_session_report_res",msgpriority="",service_name="smf-protocol",
status="accepted",transport_type="origin”} 

The SMF also maintains labels to track the number of session deletions due to the node report and session report types – GTER, SRIR, and SPTER.

For example, the label "LABEL_DISC_PDNREL_GTER_SESSION_REP" is added to track the session deletion due to the presence of GTER.

This feature involves implementing some behavioral changes to the SMF and the UPF. The new CLI configuration aids in controlling this behavior. For details on the UPF behavioral changes, see the UCC 5G UPF Configuration and Administration Guide.

Use the show running-config CLI command to verify if the feature is enabled.

show running-config 

The following configuration is a sample output of the show running-config command:

show running-config profile failure-handling interface pfcp
profile failure-handling FH1
 interface pfcp message N4SessionEstablishmentReq
  cause-code pfcp-entity-in-congestion action retry-terminate max-retry 2
  cause-code system-failure action terminate
  cause-code service-not-supported action terminate
  cause-code no-resource-available action retry-terminate max-retry 3
  cause-code no-response-received action retry-terminate max-retry 1
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionModificationReq
  cause-code mandatory-ie-incorrect action terminate
  cause-code session-ctx-not-found action terminate
  cause-code reject action terminate
 exit
 interface pfcp message N4SessionReportReq
  cause-code 69 action terminate
  cause-code 72-74,76,78-100 action terminate
 exit
exit
 

The SMF supports the following disconnect reasons as part of “smf_disconnect_stats”:

• smf_sess_pdn_rel_peer_request_reject — This disconnect reason is applicable for 4G and WiFi calls.

• smf_sess_pdu_rel_peer_request_reject — This disconnect reason is applicable for 5G calls.