The SMF supports the GTP cause code handling for 4G procedures when it detects any failure with IEs.

This section describes how to configure cause-to-class mapping and class-to-cause mapping.

For source interface failures, the cause-map-class profile determines which class-map-cause profile must be applied on the corresponding target interface, only if the latter is configured under access profile. The respective CLI configurations send the user-defined cause values to the target interface based on the source interface failures and cause values. If the CLI commands are not configured, the target interface sends the spec-driven cause values as default values.

Configuring the GTP cause codes involves the following steps:

• Cause to Class Mapping Configuration

  • Configuring Cause-to-Class Map under cause-map-class Profile

  • Configuring Cause-to-Class Map under Network-Element Profile

• Class to Cause Mapping Configuration

  • Configuring Class-to-Cause Map under class-map-cause Profile

  • Configuring Class-to-Cause Map under Access Profile

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

This section describes the GPRS Tunneling Protocol, Version 2 (GTPv2) IEs and cause codes for 4G and 5G procedures.

smf_gtpc_msg_stats

This feature supports the following statistics related to GTPC messages:

Description: Stats for GTPC interface messages

Sample Query: 'smf_gtpc_msg_stats{message_type="modify_bearer_request"}'

Labels:

• Label: message_type

  Label Description: GTPC Message Type

  Example: modify_bearer_request, delete_bearer_request, delete_session_request

• Label: status

  Label Description: GTPC message status

  Example: attempted, success, failures

• Label: reason

  Label Description: The reason associated with the failure

  Example: ipc_failed, sgw_failure, EGTP_CAUSE_LOCAL_DETACH, EGTP_CAUSE_RAT_CHANGED_FROM_3GPP_TO_NON_3GPP, EGTP_CAUSE_COMPLETE_DETACH, EGTP_CAUSE_ISR_DEACTIVATION, EGTP_CAUSE_ERROR_IND_RCVD_RNC_ENODE, EGTP_CAUSE_IMSI_DETACH_ONLY, EGTP_CAUSE_REACTIVATION_REQUESTED, EGTP_CAUSE_PDN_RECONNECTION_TO_THIS_APN_DISALLOWED, EGTP_CAUSE_ACCESS_CHANGED_FROM_NON_3GPP_TO_3GPP, EGTP_CAUSE_PDN_CONN_INACTIVITY_TIMER_EXPIRED, EGTP_CAUSE_PGW_NOT_RESPONDING, EGTP_CAUSE_NETWORK_FAILURE, EGTP_CAUSE_QOS_PARAMETER_MISMATCH, EGTP_CAUSE_REQ_ACCEPTED, EGTP_CAUSE_REQ_ACCEPTED_PARTIALLY, EGTP_CAUSE_NEW_PDN_TYPE_NETWORK_PREFERENCE, EGTP_CAUSE_NEW_PDN_TYPE_SINGLE_ADDR_BEARER_ONLY, EGTP_CAUSE_CONTEXT_NOT_FOUND, EGTP_CAUSE_INVALID_MESSAGE_FORMAT, EGTP_CAUSE_VERSION_NOT_SUPPORTED_BY_NEXT_PEER, EGTP_CAUSE_INVALID_LENGTH, EGTP_CAUSE_SERVICE_NOT_SUPPORTED, EGTP_CAUSE_MANDATORY_IE_INCORRECT, EGTP_CAUSE_MANDATORY_IE_MISSING, EGTP_CAUSE_SYSTEM_FAILURE, EGTP_CAUSE_NO_RESOURCES_AVAILABLE, EGTP_CAUSE_SEMANTIC_ERROR_IN_TFT_OPERATION, EGTP_CAUSE_SYNTACTIC_ERROR_IN_TFT_OPERATION, EGTP_CAUSE_SEMANTIC_ERROR_IN_PKT_FILTERS, EGTP_CAUSE_SYNTACTIC_ERROR_IN_PKT_FILTERS, EGTP_CAUSE_MISSING_OR_UNKNOWN_APN, EGTP_CAUSE_UNEXPECTED_REPEATED_IE, EGTP_CAUSE_GRE_KEY_NOT_FOUND, EGTP_CAUSE_REALLOCATION_FAILURE, EGTP_CAUSE_DENIED_IN_RAT, EGTP_CAUSE_PREFERRED_PDN_TYPE_UNSUPPORTED, EGTP_CAUSE_ALL_DYNAMIC_ADDR_OCCPUPIED, EGTP_CAUSE_UE_CTX_WO_TFT_ALREADY_ACTIVATED, EGTP_CAUSE_PROTOCOL_TYPE_NOT_SUPPORTED, EGTP_CAUSE_UE_NOT_RESPONDING, EGTP_CAUSE_UE_REFUSES, EGTP_CAUSE_SERVICE_DENIED, EGTP_CAUSE_UNABLE_TO_PAGE_UE, EGTP_CAUSE_NO_MEMORY_AVAILABLE, EGTP_CAUSE_USER_AUTHENTICATION_FAILED, EGTP_CAUSE_APN_DENIED_NO_SUBSCRIPTION, EGTP_CAUSE_REQUEST_REJECTED, EGTP_CAUSE_PTMSI_SIGNATURE_MISMATCH, EGTP_CAUSE_IMSI_IMEI_NOT_KNOWN, EGTP_CAUSE_SEMANTIC_ERROR_IN_TAD_OPERATION, EGTP_CAUSE_SYNTACTIC_ERROR_IN_TAD_OPERATION, EGTP_CAUSE_RESERVED_MESSAGE_VALUE_RECEIVED, EGTP_CAUSE_PEER_NOT_RESPONDING, EGTP_CAUSE_COLLISION_WITH_NETWORK_INIT_REQUEST, EGTP_CAUSE_UNABLE_TO_PAGE_UE_DUE_TO_SUSPENSION, EGTP_CAUSE_CONDITIONAL_IE_MISSING, EGTP_CAUSE_INCOMPATIBLE_APN_REST_TYPE, EGTP_CAUSE_INVALID_LENGTH_WITH_PIGGYBACK_MSG, EGTP_CAUSE_DATA_FORWARDING_NOT_SUPPORTED, EGTP_CAUSE_INVALID_REPLY_FROM_REMOTE_PEER, EGTP_CAUSE_FALLBACK_TO_GTPV1, EGTP_CAUSE_INVALID_PEER, EGTP_CAUSE_TEMP_REJECTED_DUE_TO_HANDOVER_IN_PROGRESS, EGTP_CAUSE_REQ_REJECTED_FOR_PMIPV6_REASON, EGTP_CAUSE_APN_CONGESTION, EGTP_CAUSE_BEARER_HANDLING_NOT_SUPPORTED, EGTP_CAUSE_UE_ALREADY_REATTACHED, EGTP_CAUSE_MULTI_PDN_CONNECTION_FOR_APN_NOT_ALLOWED, EGTP_CAUSE_MME_SGSN_REFUSES_DUE_TO_VPLMN_POLICY, EGTP_CAUSE_GTPC_ENTITY_CONGESTION, EGTP_CAUSE_TARGET_ACCESS_RESTRICTED_FOR_THE_SUBSCRIBER, EGTP_CAUSE_UE_TEMP_NOT_REACHABLE_DUE_TO_POWER_SAVING, EGTP_CAUSE_RELOC_FAILURE_DUE_TO_NAS_MSG_REDIRECTION, EGTP_CAUSE_MISSING_TIMESTAMP_OPTION, EGTP_CAUSE_MULTIPLE_HNP_NOT_ALLOWED, EGTP_CAUSE_SN_MALFORMED_MSG, EGTP_CAUSE_INT_TIMEOUT

• Label: qos_5qi

  Label Description: 5Qi applicable for the QoS flow

  Example: 1, 2, 5

• Label: rat_type

  Label Description: Type of the radio access associated with the request

  Example: EUTRA, NR, WLAN, rat_type_unknown

• Label: smf_current_procedure

  Label Description: Current Procedure Name for Message Level Stats

  Example: nr_to_untrusted_wifi_handover, eps_fb_ded_brr, PdnDisconnectProcedure, enb_to_untrusted_wifi_handover, pcf_req_ded_brr_create, pcf_req_ded_brr_delete, pcf_req_ded_brr_mod, smf_initiated_pdn_detach, untrusted_wifi_to_enb_handover, upf_sess_report_srir_sess_rel, utn3gpp_to_5g_handover

P-GW User Plane sends the usage report for various triggers. For example, volume, time quota, threshold, validity time, quota hold time, Start of Traffic (SoT), and so on. Otherwise, the SMF sends the query usage report after detecting a charging condition event or the removal of a Usage Reporting Rule (URR) as part of PCC Rule removal at SMF.

After receiving the usage report, the Control Plane maps the URRs to the corresponding Charging Multiple-Service Credit Control (MSCC). Then, the Control Plane initiates the Credit Control Update request for the respective MSCCs. A usage report is either synchronous or asynchronous. SMF receives the synchronous usage report through the N4 Modification Response or the N4 Deletion Response message. SMF receives the asynchronous usage report through the N4 Session Report Request message.

The usage report on the Gy interface includes the following usage report procedures:

• Start of Traffic (SoT) when Credit Control Request - Initial (CCR-I) request is not sent during the initial attach or bearer creation.

• SoT when CCR-I is sent without quota request during initial attach or bearer creation.

• SoT for predefined and static rules.

• N4 Modify Response for Query URR.

• N4 Session Report Request.

• N4 Modify Response for removal of URR.

• N4 Delete Session Response.

A Diameter Failure Handling Template is associated to different Diameter services. A Diameter endpoint pod receives a command-level failure for a Gy message from OCS. Then, the Diameter endpoint pod handles the failure handling configuration.

The following table lists the supported failure handling template actions and sub-actions for the Gy interface:

This section describes about the SMF behaviour upon receiving “failure result codes received at MSCC level” for Transient Failures (4xxx) and Permanent Failures (5xxx) result codes.

The following table explains about the various SMF transient and permanent failure result codes:

SMF receives all the permanent failure result codes and transient failure result codes 4010 and 4012 in CCAI:

• SMF sends zero time and volume quota in PFCP_SESSION_ESTABLISHMENT_REQUEST: SMF receives all the permanent failure result codes and transient failure result codes 4010 and 4012 in CCAU.

• SMF sends zero time and volume quota in PFCP_SESSION_MODIFICATION_REQUEST: SMF receives transient failure result code as 4011 in CCAI.

• SMF sends high (MAX) time and volume quota in PFCP_SESSION_ESTABLISHMENT_REQUEST: SMF receives transient failure result code as 4011 in CCAU.

This section describes about capturing the details related to processing of Multiple-Services-Credit-Control (MSCC) failure result codes at MSCC level in the Credit Control Application (CCA) messages received from Gy interface. This feature enables the SMF to process the Transient Failures (4xxx) and Permanent Failures(5xxx) at MSCC level from Gy interface in CCAI and CCAU messages.

The following table includes the various result codes and behaviour for Transient Failures (4xxx) and Permanent Failures (5xxx) result codes:

Note	Once SMF receives any supported failure codes for the URRS. No operations are performed on the URRs based on local trigger configuration or triggers received from OCS.

The following capabilities are added to the SMF as a part of this feature:

• The SMF is capable to receive Quota Validity time from Gy interface in CCAI and CCAU messages. After processing, SMF sends this information towards UPF in the following messages PFCP_SESSION_ESTABLISHMENT_REQUEST and PFCP_SESSION_MODIFICATION_REQUEST with trigger as “timqu”.

  If PFCP_SESSION_REPORT_REQUEST message receives usage report with “timqu” trigger, The SMF sends CCRU message with USU with time quota information and adds TGPPReportingReason as “VALIDITY_TIME”.

• The SMF is capable to receive Quota Holding time from Gy interface in CCAI and CCAU messages. After processing SMF sends this information towads UPF in the following messages PFCP_SESSION_ESTABLISHMENT_REQUEST and PFCP_SESSION_MODIFICATION_REQUEST with trigger as “quhti”.

  PFCP_SESSION_ESTABLISHMENT_REQUEST PFCP_SESSION_MODIFICATION_REQUEST

  If PFCP_SESSION_REPORT_REQUEST message receives usage report with “quhti” trigger. The SMF sends CCRU message with USU with time quota information and adds TGPPReportingReason as “QHT”.

Quota-Validity-Time

This is an optional AVP and may only occur in a CCA command. It is contained in the Multiple-Services-Credit-Control AVP. This field defines the time in order to limit the validity of the granted quota for a given category instance.

The following requirements are supported by SMF:

• “Validity-Time” received in Gy CCAI/CCAU messages establishment or modification

• The SMF process received validity time, if it is eligible to send the information towards UPF

  SMF Sends validity time as “tm_quta” in PFCP_IE_TIME_QUOTA and set the trigger as timqu with in PFCP_IE_REPORTING_TRIGGERS in: PFCP_SESSION_ESTABLISHMENT_REQUEST and PFCP_SESSION_MODIFICATION_REQUEST

• SMF can receive PFCP_IE_USAGE_REPORT_REP_REQ with timqu as trigger and duration in “durton_msrt” in PFCP_SESSION_REPORT_REQUEST message

• SMF process usage report sends received “durton_msrt” as “CC-Time” inside Used-Service-Unit and 3GPP-Reporting-Reason added as VALIDITY_TIME with in Multiple-Services-Credit-Control AVP in CCRU.

• If SMF received “volume_msrmt” along with “durton_msrt”, then “CC-Total-Octets“, “CC-Input-Octets“, “CC-Output-Octets“ filled along with “CC-Time” inside Used-Service-Unit and 3GPP-Reporting-Reason added as VALIDITY_TIME with in Multiple-Services-Credit-Control AVP in CCRU.

• If cnPGW not “Validity-Time” receives in Gy CCAI/CCAU messages then it read from charging profile configuration and apply it.

Quota-Holding-Time

This is an optional AVP and may only occur in a CCA command. It is contained in the Multiple-Services-Credit-Control AVP. It applies equally to the granted time quota and to the granted volume quota.

The following requirements are supported by the SMF:

• “3GPP-Quota-Holding-Time” received in Gy CCAI/CCAU messages establishment or modification

• SMF Sends holding time as “quta_hldg_tm” in PFCP_IE_QUOTA_HOLDING_TIME and set the trigger as quhti with in PFCP_IE_REPORTING_TRIGGERS in PFCP_SESSION_ESTABLISHMENT_REQUEST and PFCP_SESSION_MODIFICATION_REQUEST

• SMF can receive PFCP_IE_USAGE_REPORT_REP_REQ with quhti as trigger

• SMF process usage report 3GPP-Reporting-Reason added as QHT with in Multiple-Services-Credit-Control AVP in CCRU.

Volume-Quota-Threshold

This is an optional AVP and may only occur in a CCA command. It is contained in the Multiple-Services-Credit-Control AVP. If cnPGW and not the “3GPP-Volume-Quota-Threshold” is received in the Gy CCAI/CCAU messages, then it reads the information from the charging profile configuration and applies it.

The SMF sends the quota validity time towards the N4 in “tm_quta” in PFCP_IE_TIME_QUOTA IE. If SMF receives only Quota validity time from CCAI/CCAU or both cc-Time and validity-time are received and validity time is less. If both values are equal then SMF sends cc-Time value in tm_quta. The SMF does not forward the 3GPP-Time-Quota-Threshold to N4, if quota validity time is selected.

If received quota holding time is valid, the SMF sends the quota holding time towards the N4.

Note

Zero Validity Time: In SMF validity time or holding time values are forwarded to N4, if validity time or holding time values received from CCRI/CCRU are 0. The SMF relays 0 because honouring 0 is mechanism to disable armed timer at UPF. QVT and QHT implementation is aligned with SMF if validity time or holding time values are received from CCRI/CCRU are 0. QHT trigger received: In SMF, volume_msrmt, duration_msrmt are recived along with quhti trigger, CCRU sends volume_msrmt, duration_msrmt inside USU and updates reporting reason as QHT in MSCC level and also sends “Requested-Service-Unit”. QHT implementation is aligned with SMF if volume_msrmt, duration_msrmt are recived along with quhti trigger.

Following debug logs are present in various scenarios if validity time is received from the Gy interface:

• Only validity-Time received:

  “Validity Time present, not time quota”

• Validity-Time and cc-Time received:

  “Time Quota is smaller than validity Time”

  “Time Quota is Greater than validity Time”

  “Time Quota is equal to validity Time”

The Tarrif switch time functionality applies when a subscriber switches form one tarrif plan to another. The Tariff-Time-Change AVP is used to determine the tariff switch time, and the Monitoring-Time IE is used to support the Tarrif Time support functionality.

After a tariff timer expiry, the gateway accumulates the usage separately in a charging bucket and continues to consume from the original quota value. At the time of next reporting, (Quota exhausted or another control events) the gateway reports both usages (before and after tarrif time change) for the same charging bucket.

The SMF processes the Tariff-Time-Change AVP in Granted-Service-Unit (GSU) level from Gy interface in CCAI and CCAU messages. The SMF includes the Tariff-Change-Usage AVP inside Used-Service-Unit (USU) in CCRU and CCRT messages when the usage report is received from UPF.

Following scenarios are supported:

• Tariff-Time-Change with Quota-Holding-Time Expired Trigger

• Tariff-Time-Change with Validity-Time Expired Trigger

• Tariff-Time-Change with Volume/Time-Quota Exhausted Trigger

• Tariff-Time-Change with Volume/Time-Quota-Threshold Trigger

• Tariff-Time-Change with Immediate Reporting Trigger

• Tariff-Time-Change with Terminate Reporting Trigger

The following capabilities are added to the SMF as part of this feature:

• The OCS provides "Tariff-Time-Change" AVP in CCAI/CCAU messages. After processing, SMF sends this information towards the UPF in PFCP Session Establishment Request and PFCP Session Modification Request using PFCP_IE_MONITORING_TIME IE.

• The SMF receives two usage reports for each URR:

  • one with “Usage Report Trigger” as 'MONIT' and “ PFCP_IE_USAGE_INFORMATION” as ‘bef’ with "PFCP_IE_VOLUME_MEASUREMENT" and "PFCP_IE_DURATION_MEASUREMENT".

  • other usage report with “Usage Report Trigger” as 'TIMQU' and “ PFCP_IE_USAGE_INFORMATION” as ‘aft’ with "PFCP_IE_VOLUME_MEASUREMENT" and "PFCP_IE_DURATION_MEASUREMENT".

• The SMF uses different USU to forward both the usage reports within MSCC towards OCS in CCRU/CCRT messages.

  .

  • first usage report, one with "MONIT" trigger is forwarded in USU1 with "Tariff-Change-Usage: UNIT_BEFORE_TARIFF_CHANGE" and

  • second usage report, one with "TIMQU" tigger is forwarded in USU2 with "Tariff-Change-Usage: UNIT_AFTER_TARIFF_CHANGE ".

The Routing Data support functionality allows the SMF to:

• Process routing data received in CCA-I/CCA-U from OCS

• Override and store the routing data information in the ChargingSubData per diameter session. Smf-service includes stored routing data values in the next subsequent CCR-U or CCR-T message. The smf always expects routing data in CCA-I/CCA-U from OCS.

Monitoring and Troubleshooting

This section provides information for troubleshooting any issues that might arise during the feature operation.

The following is an example output of Routing data per Gy diameter session for a subscriber,

"gyDiamSession": {
                            "brrId": 1,
                            "sessionID": ":2:69:ocs-prof:64c37b62:1",
                            "originHost": "dummyOriginHost",
                            "originRealm": "dummyOriginRealm.com",
                            "destRealm": "dummyGyDestRealm.com",
                            "destHost": "Gy-server",
                            "RoutingData": {
                                "primaryHost": "10.105.34.14",
                                "primaryRealm": "dummyGyDestRealm.com",
                                "boundPeer": "Gy-server"
                            }
                        },

The SMF with Legacy Interface supports the Packet Data Network (PDN) attach with Gz interface for a default Bearer to enable offline accounting functions.

How It Works

On receiving offline rules from the PCRF through Gx CCA-I, SMF with the Diameter interface creates offline URRs, maps to the corresponding charging buckets (SDFs), and sends N4EstablishmentRequest toward SMF with the Legacy Interface.

On receiving the Usage report for offline SDF/Bearer level URRs, in the N4 Delete Session Response from UPF, it sends the GTPP Data Record Transfer request toward GTPP. For more information about the Gz Usage Report, see the Subscriber Charging > Gz Usage Report Handling with GTPP section.

Use the PDN attach and detach with Gz inteface functionality to:

• Attach Procedure with:

  • offline rules only (Gx+Gz)

  • offline and online rules (Gx+Gy+Gz)

• Detach Procedure with:

  • offline rules only (Gx+Gz)

  • offline and online rules (Gx+Gy+Gz)

The PDN attach and detach feature supports the following Information Element(IE):

• Reporting Level IE for offline rules: ReportingLevel for dynamic rules is received from PCRF in Gx CCA-I. The other conditions are:

  • If ReportingLevel is not present for dynamic offline rule, then SMF considers reporting level based on the RG and service ID received:

    • if only RG received then reporting level is RatingGroupLevel

    • if both RG and ServiceID received then reporting level is ServiceIdentifierLevel

  • If ReportingLevel is present for dynamic offline rule, then the same is considered.

  Note	The default offlineReportingLevel configuration is not applicable for Gz.

Handling Offline AVP for Dynamic Rules

The following table describes the function of offline AVPs for Dynamic rules.

Handling Offline Dynamic Rules when Gz is Disabled

If Gz is disabled in rulebase, no SDF and bearer level URR are created for offline dynamic rule.The table lists possible combination of input values.

If there are any path failure either from the Control Plane or User Plane, GTPP record closure with abnormal release message is sent for any one of the following reason:

• UPF session report ERIR

• UPF session report SRIR

• GTPU peer path failure

• UPF recovery release

• UPF path peer failure

• Gtpc peer path fail release

• Gtpc peer restart release

The following call flow and procedure describes PDN attach when dynamic rule with offline is enabled through Gx and Gz interfaces.

The following call flow and procedure describes PDN attach when dynamic rule with both online and offline is enabled through Gx, Gy, and Gz interfaces.

The following call flow and procedure describes the Usage report in Session Deletion Response.

Use the configuration commands to enable the Gz interface. When the offline AVP is absent at rule and command level, default offline charging method is applied for the dynamic rule. If the Gz interface is enabled, the default offline charging method for dynamic rules is enabled, else the default offline charging is disabled.

config 
   active-charging service service_name 
      rulebase rulebase_name 
         billing-records egcdr value  
   profile gtpp-profile   profile_name  gtpp dictionary dictionary_num 
   profile network-element ofcs  ofcs_name  gtpp-profile profile_name  
   profile dnn intershat network-element-profiles ofcs ofcs_name | 
end  

NOTES:

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

  Note	A rulebase is a collection of protocol rules to match a flow and associated actions to be taken for matching flow.

• billing-records egcdr value : Specify to enable eG-CDR billing to True. This associates CnPGW-C with Gz interface in the corresponding rulebase profile. Further, if PCRF sends a different rulebase in Gx CCA-I, Gz interface gets enabled or disabled as per billingRecord EGCDR configuration received in the new rulebase.

• profile gtpp-profile profile_name gtpp dictionary dictionary_num : Configure the gtpp profile with dictionary. The correct dictionary is gtpp dictionary custom24. profile_name specifies list of associated GTPP Profile names that are used in a round robin method for sessions. The maximum number of gtpp profiles allowed is 4.

• profile network-element ofcs ofcs_name gtpp-profile profile_name : Configure the network profile ofcs. The OFCS profile config allows option to configure multiple gtpp profiles.

  Note	Before configuring the network profile ofcs ensure to configure the gtpp-profile.

Use the configuration commands to set the Bearer level threshold values.

config 
   active-charging service service_name 
      rulebase rulebase_name 
         egcdr threshold volume { downlink | total | uplink }  bytes  
end  

NOTES:

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

• egcdr threshold volume { downlink | total | uplink } bytes : Specify the Bearer level URR threshold values. The limit for the number of downlink, total , or uplink octets must be an integer in the range of 100000-4000000000. Example: egcdr threshold volume downlink 100000 uplink 100000 total 200000

Use the configuration commands to set the Service Data Fow (SDF) level threshold values.

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr service-data-flow threshold volume { downlink | total | uplink } bytes  
          egcdr service-data-flow threshold interval interval   60
    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.

• egcdr service-data-flow threshold volume { downlink | total | uplink } bytes : Specify the SDF level offline URR threshold values. The limit for the number of downlink, total , or uplink octets must be an integer in the range of 100000-4000000000.

• egcdr service-data-flow threshold interval interval : Configure the threshold for offline charging. Must be an integer in the range of 60–40000000.

Use the configuration commands to create GTPP Data Record with number of Service Data Flow (SDF) container equivalent to the configured maxlosdv value. If the maxlosdv is not configured the default value is 1.

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr losdv-max-containers container_num  
    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.

• egcdr losdv-max-containers container_num : Specify the maximum List of Service Data containers (LOSDV) for creating a GTPP data record.

Use the following command to configure closure reason to send in a GTPP Data Record. The closure reason can be for mgmt-intervention or normal release. Default closure reason is mgmt-intervention.

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr closure-reason { admin-disconnect | normal-release |  }     
    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.

• egcdr closure-reason { admin-disconnect | normal-release | } : Configure the closure reason.

At the time of a converged User Plane function, the P-GW (User Plane) sends the Usage report for triggers such as Volume or Time threshold value for offline charging. During the converged Control Plane function, the P-GW (Control Plane) queries a Usage report when the Charging condition event is detected or URR is removed as part of the Policy Control and Charging (PCC) rule removal at SMF.

After receiving the Usage report, the Control Plane maps URRs to the corresponding offline charging parameter. If the offline charging parameter is not available, then a Service Data Flow (SDF) or Bearer level charging parameter is created for static or predefined rules, and the GTPP Data Record Transfer request is initiated for the respective SDFs. Thus, a Synchronous usage report is received through the N4 Modification Response or N4 Deletion Response message. Asynchronous usage report is received through the N4 Session report request message.

For more information, refer to the UCC 5G SMF Configuration and Administration Guide > Interfaces Support chapter.

The usage report on the Gz interface includes the following usage report procedures

• Offline Bearer or Offline Bearer along with SDF level, or SDF level URR for Dynamic rules

• Offline Bearer or Offline Bearer along with SDF level, or SDF level URR for Static/Predefined rules

• Online or offline URRs

• N4 Delete Session Response.

This section describes operations, administration, and maintenance information regarding support for interfaces in SMF.

SMF receives the Modify Bearer Request from S-GW for the User Location and TimeZone changes. The following functionalities are supported through triggers:

• TimeZone Trigger: Use the CHANGE_IN_UE_TIMEZONE trigger to identify timezone change

• ULI Triggers: Use the CHANGE_IN_LOCATION, CHANGEINLOCATION_TAC and CHANGEINLOCATION_ECGI to identify a location change.

Timezone information is sent only at CDR level. The following call flow depicts the Timezone change in the SMF.

Sample N4 Modification Request

PFCP_SESSION_MODIFICATION_REQUEST (52)
'Retransmit flag'  : 0
'Seid'             : 17293822569102704642
'Length'           : 71
'Sequence Number'  : 3
'Number of IEs'    : 5
    PFCP_IE_SUB_PARAMS (226)
      'sub_params' : {'rat_type': 6, 'sgsn_v4': '10.105.38.134', 'uli_len': 13, 'uli': {'spare': 0, 'ecgi': 1, 'tai': 1, 'nrtai': 0, 'nrcgi': 0, 'tai-mcc': 123, 'tai-mnc': 456, 'tai-tac': 2347, 'ecgi-mcc': 123, 'ecgi-mnc': 456, 'ecgi-spare': 0, 'ecgi-eci': 1234567}, 'ggsn_v4': '10.21.82.217'}

    PFCP_IE_QUERY_URR (77)

            PFCP_IE_URR_ID (81)
                  'urr_id' : 55

    PFCP_IE_PFCPSMREQFLAGS (49)
           'spare' : 0
           'qaurr' : 1
           'sndem' : 0
           'drobu' : 0

    PFCP_IE_QUERY_INTERFACE (253)
    'query_interface' : {'spare_3bit': 0, 'offline_urr': 0, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 1, 'sess_urr': 0}

    PFCP_IE_RECALCULATE_INTERFACE (264)
    'recalculate_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 1, 'sess_urr': 0}


        MESSAGE BUFFER:
                2134 0047 F000 0000 0000 0002 0000 0304
                00E2 001C 0100 012A 060A 6926 860D 1821
                6354 092B 2163 5400 12D6 870A 1552 D904
                004D 0008 0051 0004 0000 0037 0031 0001
                0400 FD00 0110 0108 0001 10

The User Location Information is sent at both CDR and SDFcontainer level. After the attach is performed, one CDR gets opened with the current record opening time and with current ULI. Once a CDR is generated another CDR is opened with the current record opening time and with the last user location information.

The following call flow depicts the User Location Information (ULI) change in the SMF.

Sample N4 Modification Request

PFCP_SESSION_MODIFICATION_REQUEST (52)
'Retransmit flag'  : 0
'Seid'             : 17293822569102704642
'Length'           : 71
'Sequence Number'  : 3
'Number of IEs'    : 5
    PFCP_IE_SUB_PARAMS (226)
      'sub_params' : {'rat_type': 6, 'sgsn_v4': '10.105.38.134', 'uli_len': 13, 'uli': {'spare': 0, 'ecgi': 1, 'tai': 1, 'nrtai': 0, 'nrcgi': 0, 'tai-mcc': 123, 'tai-mnc': 456, 'tai-tac': 2347, 'ecgi-mcc': 123, 'ecgi-mnc': 456, 'ecgi-spare': 0, 'ecgi-eci': 1234567}, 'ggsn_v4': '10.21.82.217'}

    PFCP_IE_QUERY_URR (77)

            PFCP_IE_URR_ID (81)
                  'urr_id' : 55

    PFCP_IE_PFCPSMREQFLAGS (49)
           'spare' : 0
           'qaurr' : 1
           'sndem' : 0
           'drobu' : 0

    PFCP_IE_QUERY_INTERFACE (253)
    'query_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 0, 'sess_urr': 0}

    PFCP_IE_RECALCULATE_INTERFACE (264)
    'recalculate_interface' : {'spare_3bit': 0, 'offline_urr': 1, 'online_urr': 0, 'radius_urr': 0, 'bearer_urr': 0, 'sess_urr': 0}


        MESSAGE BUFFER:
                2134 0047 F000 0000 0000 0002 0000 0304
                00E2 001C 0100 012A 060A 6926 860D 1821
                6354 092B 2163 5400 12D6 870A 1552 D904
                004D 0008 0051 0004 0000 0037 0031 0001
                0400 FD00 0110 0108 0001 10

Service Condition Change Reasons

Following are the service condition change reasons for the ULI change.

• If the TAI has changed in ULI, ServiceConditionChange reason in CDR is “TaiChange”

• If ECGI has changed in ULI, ServiceConditionChange reason in CDR is “EcgiChange”

• If both TAI and ECGI changes in ULI, the ServiceConditionChange reason in CDR is a generic “UserLocationChange”

The following call flow and procedure descibes Change Notification in the SMF.

The following table describes Query Interface and Recalculate Interface IEs.

To configure Gz triggers, use the following sample configuration.

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr  losdv-max-containers   service-data-flow triggers { ms-timezone-change [ true | false ] | qos-change [ true | false ] | uli-change [ true | false ] }  
    end 

NOTES:

• egcdr losdv-max-containers : Configure maximum number of LoSDV containers in one EGCDR. The losdv-max-containers value must be an integer in the range of 1–255. By default the value is 1.

• egcdr service-data-flow : Configure service data flows.

• egcdr triggers { ms-timezone-change [ true | false ] | qos-change [ true | false ] | uli-change [ true | false ] }

  • egcdr triggers : Configure list of triggers for CDR. By default, the following triggers are enabled:

    • triggers ms-timezone-change [ true | false ] : Enable or disable MS Timezone trigger for CDR default.

    • triggers qos-change [ true | false ] : Enable or disable QoS change trigger for CDR default.

    • triggers uli-change [ true | false ] : Enable or disable User Location change trigger for CDR default.

SMF supports PCRF-initiated modification of default bearer through Gx CCR-U and Gx RAR. You can perform the following functions:

• Add rules to the Default Bearer

• Delete rules from the Default Bearer

• Rulebase Modification

• Default-bearer QoS change

• APN-AMBR change

This section describes the call flows pertaining to the Gz Default Bearer Modification feature in SMF.

The SMF and UPF track the usage on eNB to differentiate the NR or LTE usage for NSA devices. SMF receives usage data report on S5 interface in various messages, which it reports usage towards OFCS server along with offline usage report.

The SMF handles the periodic Secondary RAT data volume report messages from the MME over the S5 or S8 interface in the Modify Bearer Request, Change Notification Request, Delete Session Request, and Delete Bearer Response based on the Intended Receiver PGW-C (IRPGW) flag. SMF retains the Usage-Report if IRPGW = 1.

The SMF supports multiple instances of Secondary RAT Usage Data Report IEs. It stores reports until they are sent out to OFCS based on the triggers. SMF sends out the stored secondary RAT usage data report through gtpp-ep endpoint when any of the charging triggers are met. You can configure the maximum number of stored secondary RAT usage reports under Charging Profile. SMF sends the stored secondary RAT usage data report along with offline usage report when CDR is closed due to offline usage report.

The following figure describes the call flow for Periodic Secondary RAT Usage Report.

Use the following sample configuration to configure secondary RAT usage reports before sending to OFCS.

config 
   profile charging profile_name 
      max-secondary-rat-reports report_range 
      exit 

NOTES:

• profile charging profile_name : Enter the Charging Profile configuration mode.

• max-secondary-rat-reports report_range : Configure the maximum number of secondary RAT usage reports to trigger GTPP (Gz) update. report_range must be an integer in the range of 0–50. The recommended value for secondary RAT usage limit for max-secondary-rat-reports is 25.

  Note	If the accumulated Secondary RAT usage exceeds the configured limit, the number of Secondary RAT usages exceeding the limit gets combined in a single usage.

To enable SMF to support the DCNR capability for the sessions handled using the DNN profile, use the following sample configuration:

config 
   profile dnn profile_name  intershat dcnr  
      dcnr { false | true } 
      exit 

NOTES:

• profile dnn profile_name : Specify the DNN profile name. profile_name must be an alphanumeric string.

• intershat dcnr : Enables support for dual connectivity with new radio.

  Note	The Secondary RAT usage report processing is done if the DCNR configuration is enabled, and UE has “UP plane Indication IE” in the Create Session Request.

• dcnr { false | true } :

  • false : Configure the DNN profile to have DCNR flag set to false. The DCNR configuration is disabled by default.

  • true : Configure the DNN profile to have DCNR flag set to true.

    This configuration enables the SMF to support DCNR capability. When the DCNR capability is enabled, the UE sends the DCNR flag to indicate that it supports dual connectivity.

By default, if multiple CDRs are generated for the end of a subscriber session, all the CDRs have the same cause for record closure.

The SMF through a CLI option closing-cause controls the cause for record closing in the final CDR. In case multiple CDRs are generated for the end of the subscriber session then final CDR record closure reason is set to NormalRelease and all other CDRs record closure reason is set to MaxChangeCondition.

You can suppress CDR records in the following scenarios:

• If there is no volume usage based on the CLI configuration

• If the CDR is having zero volume and if it matches the configured trigger.

• If the CDR is having zero volume and it does not match the configured trigger. If the egcdr suppress-cdrs zero-volume CLI is not configured, a CDR without any SDF containers is sent.

  Note	If a session usage report from UPF contains a SDF level usage with zero volume, the SDF container is suppressed by default.

The egcdr suppress-cdrs zero-volume CLI is applicable only for call terminanation usage report or bearer level usage cases. For example, when a call gets terminated with zero volume report or if there is a bearer level Sync or Async usage report with zero volume, the CDR to be sent out or not is determined based on the CLI configuration.

Using the following CLI configuration, to suppress the CDR records in case the CDR does not report any volume usage.

config 
    active-charging service service_name 
       charging-action charging_action 
          egcdr suppress-cdrs zero-volume   triggers [ internal-trigger-cdr |  final-cdr | external-trigger-cdr ]  
   end 

NOTES:

• egcdr suppress-cdrs zero-volume : Suppress CDRs.

• triggers : Configures one of the list of triggers that can be used to suppress CDR with zero volume:

  • egcdr suppress-cdrs zero-volume trigger internal-trigger-cdr : Specifies that an Async volume usage reporting is from UPF through PFCP session usage report.

  • egcdr suppress-cdrs zero-volume trigger final-cdr : Specifies that a call is getting terminated.

  • egcdr suppress-cdrs zero-volume trigger external-trigger-cdr : Specifies that a Sync volume usage reporting is from UPF through Query URR.

The SMF is NAS messages compliant with invalid protocol data handling as defined in 3GPP TS 24.501 with this release.

The NAS messages compliance with invalid protocol data handling feature works as follows:

• SMF ignores a NAS message that is too short to contain a complete message type information element (IE).

• SMF ignores a NAS message that is longer than the maximum limit as defined in the 3GPP specification.

• SMF ignores the IEs that are unknown in a NAS message.

• SMF ignores the IEs with incorrect sequence in a NAS message.

• If an information element with the T, TV, TLV, or TLV-E format repeats in a message with the unspecified repetition of the IE, then the SMF handles only the contents of the information element that appears first. In addition, SMF ignores the subsequent repetitions of the information element.

• SMF considers any optional IE with incorrect syntax in a message as an unavailable message.

• The network ignores any of the following messages and returns a status message with cause #100 "conditional IE error":

  • When SMF receives a NAS message with a missing conditional IE error

  • When SMF receives an unexpected conditional IE error

  • When SMF receives a message with at least one syntactically incorrect conditional IE

The SMF or vSMF supports 5G Session Management (5GSM) cause handling for the UE-initiated and network-initiated procedures.

The supported procedures are:

• PDU Session Establishment

• PDU Session Modification

• PDU Session Release

The SMF supports 5GSM cause handling for the PDU Session Establishment, PDU Session Modification, and PDU Session Release procedures. An appropriate SM cause will be sent through the N1 message to the UE.

The vSMF sends an indication toward hSMF to release the PDU session and associated resources for all session cleanups in the preceding scenarios.

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