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 the following parameters:

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

SMF supports Diff-Serv-Code-Point (DSCP) or Type of Service (ToS) QoS functions during interaction with PCF. Traffic defined at SMF can be prioritized based on the tosTrafficClass value that SMF receives from PCF. Using the ToS values provided, UPF performs DSCP packet match in the downlink direction and UE performs DSCP packet match in the uplink direction. This feature allows packet matching using ToS values, even if no FlowDescription values exist.

The following functions enable this feature:

• PCF sends tosTrafficClass IE which is part of FlowInformation within the PCC rule from PCF. SMF decodes it and stores it as part of the respective QoS Flow.

• SMF populates the tosTrafficClass IE value received from PCF in the tosTrafficClass inside SDF IE within PDI while creating the downlink PDR.

• Support for tosTrafficClass toward UE.

The following call flow describes the flow from PCF to SMF to support tosTrafficClass IE:

• You can deploy basic PCF which supports minimal functionality. The PCF need not support northbound interfaces and installs dedicated flows which are based on local configuration.

• UE only creates a single session (default bearer) to support data, voice, and video. PCF triggers four flows during PDU session creation, one each for voice, video, data, and network management.

• PCF based on local configuration sends four PCC rules each with FlowInformation carrying tosTrafficClass IE in the N7 create response.

• SMF supports flow creation for PCC rules mapped with FlowInformation having only tosTrafficClass and no FlowDescription.

• PCF may include FlowDescription within FlowInformation with filters, such as permit in IP from any to any or permit out IP from any to any.

• PCF includes QoS Data in smPolicyDecision for each of the pcc rules indicating the associated QCI. SMF creates QoS Flow for each of the QCI.

• SMF includes tosTrafficClass inside SDF IE in the downlink PDR in N4SessionEstablishmentReq to UPF while installing the rules from PCF with mapped tosTrafficClass.

• SMF sends the N1 PDU establishment response to PCF. This response includes details, such as QoS rules containing packet filters that are configured with type of service or traffic class type, based on the information that is received from PCF. If the SMF doesn't receive the flow direction from PCF, packet filter direction is populated as bidirectional and packet filter component type identifier is populated as Type of service or Traffic class type.

Note	FlowDirection is an optional parameter and its default value is bidirectional .

The Bit Rate Mapping feature complies with the following standard:

• 3GPP TS 29.274, Release 12 – 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

Use the following command to verify the status of Bit Rate Mapping feature.

show full-configuration profile network-element pcf 

If the bit rate round up is enabled within the PCF profile, then the bitrates round-up string is displayed. Otherwise, the string does not appear.

The following configuration is a sample output of this show command:

show full-configuration profile network-element pcf
profile network-element pcf pcf1
nf-client-profile PP1
failure-handling-profile FH1
query-params [ dnn ]
rulebase-prefix cbn#
predefined-rule-prefix crn#
bitrates rounded-up
exit

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 combination of QoS flow binding parameters, such as 5QI and ARP, 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 all the binding parameters except Allocation and Retention Priority (ARP) and the QCI/5QI (with or without session AMBR) in the Session Rules.

• When the QCI/5QI changes, the existing default bearer flow is modified toward N1, N2, and N4 interfaces. In this case, the SMF does not delete the existing flow instead of creating 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 following standard:

• 3GPP TS 29.512 Version 15.4.0 – 5G; 5G System; Session Management Policy Control Service; Stage 3

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

To create an instance of a quality of service (QoS) profile, use the following sample configuration.

config 
   profile qos qos_profile_name 
   exit 

NOTES:

• qos qos_profile_name : Create a quality of service profile and provide access to the QoS Profile Configuration mode to configure the QoS parameters. qos_profile_name must be an alphanumeric string uniquely identifying the QoS profile.

To configure the QoS parameters, use the following sample configuration.

config 
   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 
      exit 

NOTES:

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

• arp preempt-cap preemption_capability : Specify the preemption capability flag. The options are:

  • MAY_PREEMPT—Bearer may be preempted

  • NOT_PREEMPT—Bearer cannot be preempted

• arp preempt-vuln preemption_vulnerability : Specify the preemption vulnerability flag. The options are:

  • PREEMPTABLE—Bearer may be preempted

  • NOT_PREEMPTABLE—Bearer cannot be preempted

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

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

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

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

To configure the QoS profile in the existing DNN profile, use the following sample configuration.

config 
   profile dnn dnn_profile_name 
      qos-profile qos_profile_name 
      exit 

NOTES:

• qos-profile qos_profile_name : Define the 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.

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.

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

To define the QoS and charging related parameters associated with ruledefs, use the following sample configuration.

config 
    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 : Specify 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 : Specify 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 : Specify 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 : Configure the billing action for packets that match specific rule definitions.

• cca charging credit : Enable or disable Credit Control Application (CCA) and configure the RADIUS/Diameter prepaid charging behavior.

• content-id : Configure the rating group.

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

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

  • 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 : Configure the nexthop forwarding address.

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

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

• tft packet-filter packet_filter_name : Specify the packet filter to add or remove from the current charging action. packet_filter_name 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 : Configure the Type of Service (ToS) octets.

To configure the packet filter, use the following sample configuration.

config 
   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 : Configure the packet filters to be sent to UE. packet_filter_name must be an alphanumeric string of 1 to 15 characters.

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

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

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

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

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

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

• priority priority : Configure the priority of the current packet filter.

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.

To create, configure, or delete ACS rule definitions, use the following sample configuration.

config 
   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 : Specify 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 : Define 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 } : Define rule expressions to match IP destination address field within IP headers.

  • ipv4_address | ipv6_address : Specify 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 : Specify 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 : Specify 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 : Allow 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 } : Specify the rule application for a rule definition.

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

  • post-processing : Specify 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 : Specify 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

To combine a set of ruledefs together to apply the same charging action on them, use the following sample configuration.

config 
   active-charging service service_name 
      group-of-ruledefs ruledef_group_name 
         add-ruledef priority ruledef_priority ruledef ruledef_name 
         exit 

NOTES:

• group-of-ruledefs ruledef_group_name : Specify 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 : Specify the priority of the ruledef in the current group of ruledefs. ruledef_priority must be an integer in the range of 1–10000.

• ruledef ruledef_name : Specify the name of the ruledef to add to the current group-of-ruledefs. ruledef_name 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.

To configure the rulebase prefix and predefined rule prefix, use the following sample configuration.

config 
   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 : Specify 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 : Specify the rulebase prefix to be added. For example, the prefix for rulebase is rbn . This is a mandatory configuration for the static rule.

To enable and configure an ACS rulebase to be used for subscribers who use the configured APN, use the following sample configuration.

config 
   apn apn_name 
      active-charging rulebase rulebase_name 
      end 

NOTES:

• active-charging rulebase rulebase_name : Specify 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.

config 
   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 : Specify the name of the URR list. list_name must be an alphanumeric string of 1 to 63 characters.

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

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

• urr-id urr_id_value : Configure URR identifier for rating/service group. urr_id_value must be an integer 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 as many times as needed.

To configure the GTPP group, use the following sample configuration.

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

NOTES:

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

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

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

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

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

To configure the APN, use the following sample configuration.

config 
   apn apn_name 
   end 

NOTES:

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

To associate the GTTP group with the configured APN, use the following sample configuration.

config 
   apn apn_name 
      gtpp group group_name 
      end 

NOTES:

• gtpp group group_name : Associate 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.

To configure the ACS rulebase, use the following sample configuration.

config 
   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 : Specify 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 ] } : Configure the priority order in which ruledefs are matched and the associated charging action.

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

  • monitoring_key must be an integer 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 ] } : Configure the quota for online charging.

  • holding_time must be an integer in the range of 1–4000000000

  • content_id must be an integer in the range of 1–2147483647

  • retry_time must be an integer in the range of 0–86400

  • retries must be an integer in the range of 1–65535

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

  • consumed_time must be an integer in the range of 1–4294967295 seconds

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

  • continuous_time must be an integer in the range of 1–4294967295 seconds

  • parking_meter must be an integer in the range of 1–4294967295 seconds

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

• dynamic-rule order : Configure the order of dynamic rule matching against the static rules in a rulebase.

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

  • interval must be an integer in the range of 60–40000000.

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

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

  • total must be an integer 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 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 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 in the range of 100–30000. Default value is 5000.

To configure the UPF APN profile in the existing DNN profile, use the following sample configuration.

config 
   profile dnn dnn_profile_name 
      upf apn apn_name 
      end 

NOTES:

• upf apn apn_name : Enable UPF APN profile configuration. This profile is configured under the existing DNN profile configuration. apn_name must be an alphanumeric string of 1 to 62 characters.

To configure the QoS parameters, use the following sample configuration.

config 
   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 
      exit 

NOTES:

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

• arp preempt-cap preemption_capability : Specify the preemption capability flag. The options are:

  • MAY_PREEMPT—Bearer may be preempted

  • NOT_PREEMPT—Bearer cannot be preempted

• arp preempt-vuln preemption_vulnerability : Specify the preemption vulnerability flag. The options are:

  • PREEMPTABLE—Bearer may be preempted

  • NOT_PREEMPTABLE—Bearer cannot be preempted

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

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

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

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

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

To verify the feature configuration details, use the following command.

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 = 209.165.201.0/27 
  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 = 209.165.201.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 

To verify the group-of-ruledefs configuration details, use the following command.

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.

To verify the bandwidth ID configuration, use the following show command:

show config 

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:

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 selects UPF from a list of all active UPFs based on the predefined query parameters.

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

When the UPF selection is based on the load of the UPFs, the SMF distributes calls among active UPFs associated with SMF. 3GPP specifies Load Control feature as optional feature over N4 reference points. This functionality 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 available in section 6.2.3 of 3GPP TS 29.244, Release 14. The 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 UPF selection policy configured under DNN profile configuration. The UPF selection policy defines a combination of the following parameters:

  • DNN

  • Network slice

  • Subscriber location

  • DCNR (only for EPS calls)

  • PDN/PDU subscription type

  • PDN/PDU session type

• If the UPF selection policy is not defined under DNN profile configuration, then SMF selects the UPF based on the derived location DNN or requested DNN

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

• If multiple UPFs match the 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 the new sessions. 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, the SMF uses the configured capacity to select the UPFs.

This section describes how to configure the UPF Selection feature.

The UPF selection depends on the query parameter. Use the following configurations based on the selected query parameter.

• Creating the ECGI Group Profile for EPS Session

• Creating the NCGI Group Profile for 5GS Session

• Configuring Tracking Area Identity Group

• Creating the Location-Area-Group Profile

• Defining the UPF Group

• Associating the UPF Group with UPF Network Element

• Defining UPF Selection Query Parameters

• Associating UPF Selection Query Parameters with DNN Profile

• Configuring UPF Address

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

The converged core gateway with the cnSGWc and SMF supports selection of a converged UP node to realize convergence. With this functionality, it is possible to create an optimized data path for the UE.

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

This section describes how the SMF handles the co-located UPF selection during PDN Session Establishment in 4G network.

When the SGW-U node name is available in the CSR, SMF derives the UPF from the configuration based on the node name.

Then, SMF uses the existing UPF selection logic and derives the list of UPFs accordingly. The SMF checks if the SGW-C selected UPF exists in the derived UPF list.

If the SGW-C selected UPF is present in the derived UPF list and if its priority matches with the highest priority in the derived UPF list, then SGW-C selection UPF is selected. Otherwise, priority UPF in the derived list is selected.

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

To select the co-located UPF, use the following sample configuration.

config 
   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

During the UE session establishment in 5G core network, the SMF uses the existing UPF selection logic and records the index of the selected UPF in PGW-C Control Tunnel Endpoint Identifier (TEID).

Upon receiving Create Session Request (CSR) from MME, cnSGWc checks whether or not the TEID value is zero. If it is zero, then cnSGWc sends Remote Procedure Call (gRPC) message to SMF and fetches UP ID and UPF IP.

If the TEID is non-zero, the SMF checks the bits from 21 through 30 of control TEID value, and extracts the UPF index. The SMF uses the extracted UPF index to select the preferred UPF.

The SGW-C uses this as the preferred UPF when the UE session is handed over to EPS network. If the preferred UPF is present in the list returned by the UPF selection algorithm, then the cnSGWc selects the UPF with highest priority. That is, the cnSGWc selects the same UPF that was chosen by SMF. This operation enables creating an optimized data path for the UE.

If the preferred UPF does not exist in the returned list, cnSGWc selects a different UPF.

This section describes how to perform co-located UPF selection during handover scenario.

Configuring the parameters for co-located UPF selection involves the following steps:

• Enabling Co-located UPF Selection

• Configuring Index and Session Count for UPF Selection

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 the following standard:

• 3GPP TS 29.244 Version 15.6.0 – LTE; Interface between the Control Plane and the User Plane nodes

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 when the following configuration is performed on CEE Ops-Center. This alarm indicates that a GTP-U peer for a particular UPF has gone down. The alarm data includes GTP-U peer IP and UPF IP addresses.

The following is a sample configuration performed on the CEE Ops-Center to configure alert rules related to the UPF Node Report Request.

config 
   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 

NOTES:

• alerts rules : Specify the Prometheus alerting rules.

• group alert_group_name : Specify 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 : Specify the evaluation interval of the rule group in seconds.

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

The following is an example configuration of the alert.

config 
   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 and GTP-U peer endpoint key. This configuration data helps to identify the failed sessions or collision of procedures.

The following is an example 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/209.165.202.129",
      "ipv4-pool:poolv4",
      "ipv4-range:poolv4/209.165.202.129",
      "ipv4-startrange:poolv4/209.165.202.129",
      "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 an example 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.

UPF measures the volume and the time usage of all traffic for the PDU session or the corresponding service data flows. UPF sends the accumulated usage report in either the PFCP Session Report Request or the PFCP Session Modification Response to SMF. Then, SMF includes one or multiple accumulated usage reports in the "accuUsageReports" attribute in one of the following messages towards PCF.

• HTTP POST message

  Note	This message also includes the "US_RE" value in the "repPolicyCtrlReqTriggers" attribute.

• Message to include the SM Policy Delete Data data structure during the terminate procedure.

Each AccuUsageReport data structure includes the accumulated usage within one or two usage report information elements. These elements are corresponding to a usage monitoring control instance that PCF requested. If the PCF provides both volume and time thresholds and the threshold for one of the measurements reaches, then the UPF communicates this event to the SMF along with the accumulated volume and time measurements. Then, SMF sends the accumulated usage since the last report to PCF for both the measurements.

The SMF receives the accumulated usage report from UPF in the PFCP Session Report Request. After receiving this report, the SMF identifies the list of usage report corresponding to the usage monitoring control instance. Then, SMF posts a PDU Modify or PDU Dedicated bearer procedure. This procedure includes new event type, list of usage reports, and the list of URRs to process them.

Following are the available data modification scenarios for the usage monitoring over PCF.

• If the PCF needs to remove the threshold level for one or multiple monitoring keys, the PCF provides the corresponding attribute with the NULL value to the corresponding usage monitoring control instance.

• When the PCF receives the accumulated usage in the HTTP POST message, the PCF communicates to SMF whether the usage monitoring continues for the following usage monitoring control instance:

  • If the monitoring continues for the specific levels, the PCF provides the new thresholds for the levels in the response of the HTTP POST message. This message includes the existing attributes, such as "volumeThreshold", "volumeThresholdUplink", and "volumeThresholdDownlink".

  • If the PCF stops monitoring for the specific levels, the PCF doesn't include an updated threshold in the response of the HTTP POST message for the stopped levels. It implies that PCF doesn't include the corresponding attributes in the entry of the "umDecs" attribute. These attributes are "volumeThreshold", "volumeThresholdUplink", "volumeThresholdDownlink", "timeThreshold", "nextVolThreshold", "nextVolThresholdUplink", "nextVolThresholdDownlink", and "nextTimeThreshold".

If the PCF stops the monitoring for the usage monitoring control instance, the PCF doesn't include any thresholds of the usage monitoring control instance in the response of the HTTP POST message. In addition, the PCF doesn't remove the reference of the usage monitoring control instance from the dynamic PCC rule or session rule.

Based on the following scenarios, SMF sends the PFCP Session Modification Request to PCF:

• In case of modification in the existing thresholds, SMF updates the URR with the new thresholds and initiates Update URR towards UPF in the PFCP Session Modification Request.

• In case of stopped monitoring for the usage monitoring control instance, SMF removes the URR and initiates Remove URR toward UPF in the PFCP Session Modification Request.

• In case of new usage monitoring control instance, SMF creates a new URR with the thresholds. SMF also associates the URR to the corresponding PDRs and initiates Create URR along with Update PDR toward UPF in the PFCP Session Modification Request.

While provisioning the usage monitoring on SMF and its actions, following errors can occur:

• If PCF has defined invalid thresholds, the SMF marks the PCC rule as failed or invalid when the Session rule or PCC rule has the reference of monitoring key (UmId) with the invalid thresholds.

• If PCF removes or doesn't configure the US_RE flag between the message exchanges where usage monitoring is active in the SMF, the SMF sends the Remove URR request to UPF in the Modification Request with the available URRs that are created for the N7 interface.

This section describes the following call flows.

• Usage Monitoring Activation call flow

• Usage Reporting call flow

The usage monitoring over PCF feature complies with the following standards.

• 3GPP TS 29.512 version 16.5.0 Release 16—5G; 5G System; Session Management Policy Control Service

This feature has the following limitations:

• If you have enabled the PCC Rule level monitoring, then by default this monitoring gets linked with the URR of the refUmData that is associated with the PCC rule and Session level URR, if exists. The linking exists until PCF excludes it from the session level monitoring in "exUsagePccRuleId".

• While the usage monitoring is in progress, any update of parameters from PCF for a Session or PCC rule without refUmData implies disabling or removal of usage monitoring for that rule. This rule must always include the refUmData even if no change exists.

• SMF doesn't honor the usage report received from UPF after SMF notifies the usage report to PCF and PCF responds with 204—No Content (PCF disables the usage monitoring). In this case, SMF notifies only the UPF with the remove URR for the disabled UmId and locally discards any received usage report.

• By default, SMF links the URR, if it exists, of the Session level to all the active static rules as part of the session. As no URR information exchange happens for static rules between SMF and UPF, the UPF is responsible to monitor the static rules data usage as part of the PDU and Session level monitoring. Then, UPF sends the response to SMF through the Usage report.

To verify the configuration, use the following command:

show running-config active-charging service active-charging_service_name rulebase rulebase_name action priority action_priority dynamic-only ruledef  

If the usage monitoring key is configured, then the value appears as part of the umid configuration in the following output.

show running-config active-charging service acs1 rulebase rba1
   active-charging service acs1
      rulebase rba1
         action priority 1 dynamic-only ruledef rda1 charging-action ca1 description myrule1
         action priority 2 dynamic-only ruledef rda1 charging-action ca1 description myrule2 umid 54
         action priority 3 dynamic-only ruledef rda3 charging-action ca3 description myrule3
      exit
     exit 

The SMF-Service (smf-service) pod supports the following statistics:

PolicyPcfUpdatesTotal

• Description: Display the number of times Usage Report sent towards PCF.

• Metrics-Type: Statistics

• Labels:

  • Label: smf_current_procedure

    • Description: Display the current running procedure.

    • Value: PDU Session Modify – PCF-initiated or PDN Session Modify—Bearer Add, Delete, or Modify

  • Labels:

    • Label: trigger

      • Description: Displays the trigger for the procedure initiated at SMF

      • Value: usage_report