Managing Multi-Generation Device Support with Unified SMF

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Platform(s)

SMI

Feature Default Setting

Enabled – Configuration Required

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

Periodic Secondary RAT Usage Data Report is supported from MME over S5/S8 interface in the Modify-Bearer-Request, Delete-Session-Request, Delete-Bearer-Response, and Change-Notification-Request

2023.04.0

Added the extended QoS support for SMF with the legacy interfaces.

2023.02.0

The Phase-2 support for 4G-UE and Option-3x feature includes:

  • DCNR based UPF selection

  • Handling Secondary RAT Data Usage Report from S-GW/MME and relaying it to CHF

  • UE Presence Reporting

  • Handling GTPV1 messages for 4G to 3G handover

  • SUPI+IP session and affinity key for 4G and WiFi handover

  • Avoiding sending of 5G QoS for 4G-only UE

  • Handling 5GCNRS and 5GCNRI indication flags from S-GW/MME

2021.01.0

First introduced.

2020.03.0

Feature Description


Important


The PGW-C term used in this chapter denotes the EPS interworking functionality supported by SMF and must not be assumed as a standalone P-GW that is used in the LTE network.


The dual connectivity enabled UEs support 4G LTE and 5G NR. Such UEs send a signal to the 4G Core Network, indicating that it’s a dual connectivity-enabled device.

When the Dual Connectivity New Radio (DCNR)-capable UE attempts to register in an MME, the MME sets the "UP Function Selection Indication Flags" IE with the DCNR flag set to 1 in the Create Session Request message. After the S-GW receives this IE over S11, it sends the IE over S5 to PGW-C. This IE transmission helps the SGW-C and PGW-C to select SGW-U and UPF, which supports dual connectivity with NR.

The SMF and PGW-C support Packet Data Unit (PDU) sessions from both the 4G-only capable device and the Option 3x capable device (NR and LTE radio connected to the EPC).

The SMF supports the following features and functionality:

DCNR-based UPF Selection

The SMF selects DCNR supported UPF for DCNR enabled session if DCNR is configured under query parameters. DCNR isn’t a mandatory query parameter for UPF selection. You can configure DCNR under the UPF Group profile.

For more information, refer to the UPF Node Selection section in the Policy and User Plane Management feature chapter.

Secondary RAT Data Usage Report

The SMF and UPF track the usage on eNB to differentiate the NR or LTE usage for NSA devices. SMF receives usage data ports on the S5 interface in various messages and reports the usage towards CHF.

The SMF handles the periodic Secondary RAT Usage Data Report from MME over the S5 or S8 interface in the Modify Bearer Request, Delete Session Request, Delete Bearer Response, and Delete Bearer Command 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 CHF 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.

Presence Reporting Area

Presence Reporting Area (PRA) is an area defined within the 3GPP packet domain for reporting UE presence within that area due to policy control and/or charging reasons. For E-UTRAN, a PRA consists of a set of neighbor or non-neighbors tracking areas, eNBs and/or cells. You can enable the PRA functionality under the DNN profile.

The two types of Presence Reporting Areas that apply to an MME pool are UE-dedicated Presence Reporting Areas and Core Network preconfigured Presence Reporting Areas. SMF supports Core Network preconfigured PRAs.

4G to 2G or 3G Handover

During 4G to 2G or 3G handover, the SMF rejects the GTPv1 message request and reattaches with 2G or 3G for nondisrupted service continuity. If SMF drops the request, it delays the handover failure and subsequent attach to 2G or 3G.

Extended QoS Support with Legacy Interfaces

When the DCNR-enabled 4G devices connect to the SMF with the legacy interfaces and the Extended-BW-NR feature is negotiated with PCRF, the SMF sends the APN-AMBR values that are greater than 4.2 Gbps towards PCRF in the extended Bit-rates AVP.

If the SMF receives APN-AMBR values greater than 4.2 Gbps in the GTP-v2 messages from S-GW and the DCNR feature isn’t enabled, then the SMF limits the APN-AMBR value to 4.2 Gbps.

If the SMF receives extended QoS values from PCRF and the session isn’t DCNR-enabled, then the SMF limits the APN-AMBR value to 4.2 Gbps.

How it Works

The SMF generates a PDU session ID (pdu-session-id) upon receiving a Create Session Request from the 4G-only UE. The SMF validates if the request has the EPS interworking indication without the PDU session ID in the Protocol Configuration Option. The UDM provides the interworking indication to the SMF per DNN. The SMF does not use this indication for deciding whether the UE is 5G capable.

The SMF generates a pdu-session-id based on Linked EPS Bearer Identity (LBI). For the 4G sessions, the pdu-sesion-id is LBI+64 and for the Wi-Fi sessions, the pdu-session-id is LBI+80.

The SMF allows you to configure the default NSSAI under the profile DNN. The NSSAI is part of sliceInfo IE sent in the Policy Create Request to the PCF during session creation from 4G-only UEs. If the default slice is not configured, then SMF selects one of the configured slices.

When the UE is DCNR capable, and the DCNR is enabled for the session, the SMF considers that the UE is capable of supporting dual connectivity. You can configure DCNR per DNN and other NFs, such as UPF. The S-GW notifies the DCNR support to PGW-C through the UPF Selection Indication Flags IE.

Standards Compliance

The Option 3x and 4G-Only Device feature complies with the following standards:

  • 3GPP TS 23.003 [2]

  • 3GPP TS 24.301 [23]

  • 3GPP TS 29.272 [70]

  • 3GPP TS 29.274

  • 3GPP TS 29.212

Limitations

This feature has the following limitations:

  • Ultra low latency QCIs are not supported.

  • PRA:

    • PRA is supported only towards PCF and not CHF.

    • PRA is applied only based on RAT type of the connecting device and not based on the device type. It is applied to both 4G and 5G devices when connected from LTE.

    • A maximum of four PRA-IDs are processed in a single PCF update message. If a PCF update has more than four PRA-IDs, then the other PRA-IDs are ignored.

    • Only the PRA-ID will be sent in the "Presence Reporting Area Action" IE on S5 interface. User location information will not be sent.

    • Only the PRA-ID will be sent in the "repPraInfos" IE on N7 interface. User location information will not be sent.

    • PRA Set is not supported due to which "Additional PRA Information" is not supported on S5 and N7 interfaces.

  • Secondary RAT Data Usage Report:

    • Supports only Option 3 and Option 3x (NR Secondary RAT) UEs on S5 interface.

    • Does not support E-UTRAN Secondary RAT on N2 interface.

Configuring Parameters to Support 4G and 5G Devices

This section describes how to configure the SMF with the capabilities to support 4G and 5G devices.

Configuring this feature involves the following steps:

Configuring the NSSAI

This section describes how to configure the default NSSAI in SMF, which it includes in sliceInfo IE in the Policy Create Request message. The SMF sends this message towards the PCF during the session creation from 4G-only UEs.

Use the following sample configuration to configure the default NSSAI in the SMF:

config 
   profile dnn profile_name 
      nssai { sd sd_value | sst sst_value } 
      exit 

NOTES:

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

  • nssai { sd sd_value | sst sst_value } : Configure the default NSSAI.

    • sd sd_value : Specify the slice descriptor (sd). sd_value must be a 6-digit hex string ([0-9a-fA-F]{6} - 000000 – ffffff). For example, 1A2B3c.

    • sst sst_value : Specify the slice type (sst) value. sd_value must be an integer in the range of 0–255.

Enabling DCNR in DNN Profile

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    
      dcnr { false | true } 
      exit 

NOTES:

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

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

Configuring UPF Selection

This section describes how to enable the DCNR flag and configure the appropriate precedence for DCNR.

Defining the UPF Group

Use the following sample configuration to configure the UPF group and define DCNR in the UPF Group profile.

config 
   profile upf-group profile_name 
      dcnr { false | true } 
      exit 

NOTES:

  • profile upf-group profile_name : Specify the UPF group name that must be associated to the specified UPF network configuration. profile_name must be an alphanumeric string.

  • dcnr { false | true } : Configure the DCNR capability.

    • false : Disable support for DCNR. This is the default setting.

    • true : Enable support for DCNR.

Associating UPF Selection Query Parameters

Use the following sample configuration to associate the defined UPF group with the UPF network element in the DNN profile.

config 
   profile dnn profile_name 
      upf-selection-policy  upfpolicy_name 
      exit 

NOTES:

  • policy dnn profile_name : Enter the DNN Profile configuration mode. profile_name must be an alphanumeric string.

  • upf-selection-policy upfpolicy_name : Specify the name of the UPF selection policy that must be associated to the DNN profile. upfpolicy_name must be an alphanumeric string.

Configuring Precedence for DCNR

Use the following sample configuration to configure the appropriate precedence for DCNR in the UPF Selection Policy profile.

config 
   policy upf-selection upf_name 
      precedence precedence_num 
         dcnr 
         exit 
      exit 

NOTES:

  • policy upf-selection upf_name : Specify the UPF policy name that must be associated with the DNN profile. profile_name must be an alphanumeric string.

  • precedence precedence_num : Assign the precedence value to the UPF policy. precedence_num must be an integer in the range of 1–4.

  • dcnr : Configure the DCNR capability.

Configuring Secondary RAT Usage Report

Use the following sample configuration to configure secondary RAT usage reports before being sent to CHF.

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) or CHF update. report_range must be an integer in the range of 0–50. Default value: 0.

Configuring Presence Reporting

Use the following sample configuration to configure presence reporting.

config 
   profile dnn dnnprofile_name 
      presence-reporting { false | true } 
      exit 

NOTES:

  • profile dnn dnnprofile_name : Enter the DNN Profile Configuration mode.

  • presence-reporting { false | true } : Configure presence reporting for the DNN.

    • false : Disable presence reporting. This is the default setting.

    • true : Enable presence reporting.

Configuration Verification

To verify the configuration, use the following command:
show subscriber supi supi_id nf-service smf  

In the output of the preceding show command, check the value associated with the field "dncr". This field displays one of the following values:

  • Enabled

  • None

  • UE Requested and Enabled

If the feature is configured, then the "dcnr" field displays "Enabled".

The following configuration is an example output of the show subscriber supi nf-service smf command:

unknown] smf# show subscriber supi imsi-123456789012345 nf-service smf
subscriber-details 
{
"subResponses": [
{
"status": true,
"genericInfo": {
……
},
"sScMode": 1,
"chargEnabled": true,
"uetimeZone": "+00:15+1",
"allocatedIp": "209.165.201.12",
"eUtranLocation": {
"ecgi": {
"mcc": "123",
"mnc": "456",
"eutraCellId": "1234567"
},
"tai": {
"mcc": "123",
"mnc": "456",
"tac": "1820"
}
},
"alwaysOn": "None",
"dcnr": "Enabled",   
……
"policySubData": {
 "TotalDynamicRules": 3,
…………
Presence Information: "Enabled",   
 "praIdList": [  -> list of all enabled PRA IDs
          "8388608",  Status = IN
          "8388618" Status = OUT
        ]
 },

OAM Support

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

Statistics Support

The SMF uses the "dcnr" label in the session gauge "smf_session_counter" and "smf_service_stats" for collecting the DCNR session count. When the SMF session is DCNR supported, the "dcnr" label value is enabled. The label does not support non-DCNR sessions.

The following is a sample query to count the active DCNR SMF sessions:

nts{action_type="rejected",app_name="smf",cluster="smf",data_center="unknown",
failure_type="hdr_decode_failure",hdr_decode_fail_reason="",instance_id="0",interface_type="
",message_type="",reject_cause="",service_name="gtpc-ep"} 2
smf_session_counter: sum (smf_session_counters{dcnr_on="enable"}) by (dcnr)
smf_service_stats: sum (smf_session_stats{dcnr_on="enable"}) by (dcnr, status, reason)
smf_session_counters{ presence-reporting ="enable"}) by (presence-reporting)

DCNR Session Count

For DCNR, Session Count supports the "dcnr" label in the existing session gauge "smf_session_counter". If the SMF session is a DCNR session, then the "dcnr" label value is "enable", otherwise it is "disable" for DCNR session.

The following is a sample query to count the DCNR active SMF sessions:

sum (smf_session_counters{dcnr_on="enable"}) by (dcnr)

For DCNR statistics, the existing "smf_service_stats" counter supports the "dcnr" label. For DCNR sessions, this counter pegs the following labels and values:

  • Attempt Statistics – dcnr= "enable" and status= "attempted"

  • Success Statistics – dcnr= "enable" and status= "success"

  • Failure Statistics – dcnr= "enable" and status= "failures"

The following is a sample query for DCNR statistics:

sum (smf_session_stats{dcnr_on="enable"}) by (dcnr, status, reason)

Secondary RAT Data Usage Reports

The Secondary-Rat-Data-Usage-Reports support the "smf_secondary_rat_usage_report_stats" counter. Labels for these statistics include ebi, qfi, rat_type, reason, service_name, and status. This counter pegs with the following labels and values:

  • ebi=ebi-val

  • qfi=qfi-val

  • rat_type=NR

  • reason=success/failure

  • service_name=smf-service

  • status=ReceivedFromSgw/SentToChf

The following is a sample query for DCNR statistics:

sum (smf_secondary_rat_usage_report_stats”) by (qfi, status, reason)

Presence Reporting

For Presence Reporting, Session Count supports the "pra" label in the existing session gauge "smf_session_counter". If the SMF session has presence reporting enabled, then the "presence-reporting" label value is "enable" else it is "none" if presence reporting is not enabled.

The following is a sample query to count the DCNR active SMF sessions:

sum (smf_session_counters{ pra ="enable"}) by (pra)

For Presence Reporting, statistics support the "presence-reporting" label in the existing counter "smf_service_stats". For presence-reporting session, this counter pegs the following labels and values:

  • Attempt Statistics – pra = "enable" and status= "attempted"

  • Success Statistics – pra = "enable" and status= "success"

  • Failure Statistics – pra = "enable" and status= "failures"

The following is a sample query for DCNR statistics:

sum (smf_session_stats{ pra ="enable"}) by (pra, status, reason)

Bulk Statistics

The Option 3x and 4G-Only Device feature supports the following bulk statistics in SMF schema:

Bulk Statistics Name

Statistics Type

Trigger

Description

smf_session_counters

Gauge

Increments or decrements for session attach or detach.

Indicates the total number of currently active SMF sessions. You can filter the active session using labels, such as "dcnr=enable" for the DCNR session count.

smf_session_stats

Counter

Increments for success or failures of the call flow.

Indicates the statistics for call flow states such as attempted, success, and failures. You can filter the statistics using labels, such as “dcnr=enable” for only DCNR statistics.

The Secondary RAT Data Usage Report functionality supports the following bulk statistics:

smf_secondary_rat_usage_ report_stats

Counter

Increments for the status of the secondaryRatDataUsage Report processing.

Displays the statistics for secondaryRatUsageReports processing for call flow status such as "ReceivedFromSgw" and "SentToCHF". You can filter the statistics using labels, such as reason and QFI.

OFCS_CDR_MESSAGE_STATS

Counter

A new label "Trigger Type" captures the event when a configured Secondary RAT usage limit is reached. The trigger type label contains "GZ_SECONDARY_RAT_USAGE_LIMIT_REACHED" value.

The PRA functionality supports the following bulk statistics:

smf_session_counters

Gauge

Increments or decrements for session attach or detach.

Indicates the total number of current active SMF sessions. You can filter the session using labels, such as "pra=enable" for the presence reporting enabled session count.

smf_session_stats

Counter

Increments for success or failures of the call flow.

Indicates the statistics for call flow states such as attempted, success, and failures. You can filter the statistics using labels, such as “pra=enable” for only presence-reporting statistics.

Troubleshooting Information

This section provides information on using the command line interface (CLI) commands, alerts, logs, and metrics for troubleshooting issues that may arise during system operation.

Subscriber Details with DCNR and Presence Reporting Enabled

The show subscriber nf-service smf supi supi_id full CLI command displays the DCNR active session with presence reporting enabled for the Option-3x feature.


Note


In 2021.02 and later releases, the namespace keyword is deprecated and replaced with the nf-service keyword.


[unknown] smf# show subscriber nf-service smf supi imsi-310260789012345 full

subscriber-details 
{
  “subResponses”: [
    {
      “status”: true,
      “genericInfo”: {
        “supi”: “imsi-310260789012345”,
        “pei”: “imei-123456786666660”,
        “pduSessionId”: 5,
        “pduSesstype”: “Ipv4PduSession”,
        “accessType”: “3GPP_ACCESS”,
        “dnn”: “fast.t-mobile.com”,
        “plmnId”: {
          “mcc”: “123”,
          “mnc”: “456”
        },
…
        “alwaysOn”: “None”,
        “dcnr”: “Enabled”,
        “wps”: “Non-Wps Session”,
        “ratType”: “EUTRA”,
        “ueType”: “NR Capable UE”,
        “iwkEpsInd”: true,
        “sessTimeStamp”: “2021-01-12 12:40:39.931012285 +0000 UTC”,
        “callDuration”: “4m25.36784895s”,
        “ipPool”: “poolv4”,
        “commonId”: 16777223,
        “linkedEbi”: 5,
        “smfIwkEpsInd”: true,
        “snssai”: {
          “sd”: “Abf123”,
          “sst”: 1
        },
        “authStatus”: “Unauthenticated”,
        “roamingStatus”: “Roamer”,
        “uePlmnId”: {
          “mcc”: “310”,
          “mnc”: “260”
        }
      },
      “policySubData”: {
        “TotalDynamicRules”: 2,
        “TotalFlowCount”: 2,
        “TotalNonGBRFlows”: 1,
        “TotalGBRFlows”: 1,
        …
        “presenceReporting”: “Enabled”,
        “praList”: [
          {
            “praId”: “0x80000b”,
            “presenceState”: “Inactive”
          },
          {
            “praId”: “0x800000”,
            “presenceState”: “InArea”
          },
          {
            “praId”: “0x80000a”,
            “presenceState”: “OutOfArea”
          }
        ]
      },
      …
      }
    }
  ]
}

Option-3x: DCNR Enabled UE Alerts

This section describes the alerts supported for DCNR enabled UEs with presence-reporting enabled. You can enhance these alerts as per 4G procedure or as per the intent of the end user.

Examples of DCNR statistics or gauges are pdn_sess_create, pdn_inter_sgw_handover, pdn_mbr, pcf_req_ded_brr_mod, pcf_req_ded_brr_create, pcf_req_ded_brr_delete, delete_session_request, smf_initiated_pdn_detach, ue_req_pdn_sess_rel, and so on.

DCNR UE Attach Failure Threshold Alert

Use the following example to configure alerts related to DCNR UE Attach Failure Threshold.

alerts rules group DCNRUEs
 rule DCNR_UE_SR
  expression "sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", dcnr=\"enable\", rat_type!=\"EUTRA\", status=\"success\", procedure_type=\"pdn_sess_create\"}[5m])) / sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", dcnr =\"enable\", rat_type!=\"EUTRA\", status=\"attempted\", procedure_type=\"pdn_sess_create\"}[5m])) < 0.10"
  severity   major
  type       "Communications Alarm"
  annotation summary
   value "This alert is fired when attach success rate of DCNR enabled UE lesser than threshold"
  exit
 exit

DCNR UE Attach Failure Threshold Alert with Presence Reporting

Use the following example to configure alerts related to DCNR UE Attach Failure Threshold with presence reporting enabled.

rule DCNR_UE_PRA_ENABLE_SR
  expression "sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", dcnr=\"enable\", rat_type!=\"EUTRA\", status=\"success\", procedure_type=\"pdn_sess_create\", pra=\"enable\"}[5m])) / sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", dcnr =\"enable\", rat_type!=\"EUTRA\", status=\"attempted\", procedure_type=\"pdn_sess_create\", pra=\"enable\"}[5m])) < 0.10"
  severity   major
  type       "Communications Alarm"
  annotation summary
   value "This alert is fired when attach success rate of DCNR enabled UE and presence reporting enabled lesser than threshold "
  exit
 exit

DCNR UE Bulk Statistics

Use the following SMF service bulk statistics to monitor the failures or issues associated with DCNR UEs.

Table 3. DCNR UE
Bulk Statistics Name

Query

Description

4G_DCNRUE_Attempted

bulk-stats query 4G_DCNRUE_Attempted expression "sum(smf_service_stats {dcnr='enable',status='attempted', rat_type='EUTRA'}) by (namespace)" exit

4G_DCNRUE_Success

bulk-stats query 4G_DCNRUE_Success expression "sum(smf_service_stats {dcnr='enable',status='success', rat_type='EUTRA'}) by (namespace)" exit

4G_PRA_ENABLE_Attempted

bulk-stats query 4G_PRA_ENABLE_Attempted expression "sum(smf_service_stats {pra='enable',status='attempted', rat_type='EUTRA', procedure_type!='create_session_request'}) by (namespace)" exit

4G_PRA_ENABLE_Success

bulk-stats query 4G_PRA_ENABLE_Success expression "sum(smf_service_stats {pra='enable',status='success', rat_type='EUTRA', procedure_type!='create_session_request'}) by (namespace)" exit

Option-3x Device Specific Error Logs

This section provides the basic error conditions and logs that are captured to debug the failures for the Option-3x feature.

DCNR Disabled UE or 4G capable UE only

The following example displays the error log for DCNR disabled UE or 4G capable UE only.

2021/01/24 10:11:22.648 smf-service [ERROR] [GenericGtpMsg.go:1811] [smf-service.smf-app.sgw] secRatUsageRpt recvd wrongly for DNCR disbled UE, ignoring report

2020/12/19 13:17:17.834 smf-service [ERROR] [GenericGtpMsg.go:1834] [smf-service.smf-app.sgw] secRatUsageRpt recvd wrongly for 4gOnly UE, ignoring report

Secondary RAT Usage with invalid EBI

The following example displays the error log for secondary RAT usage with invalid EBI.

2021/01/24 11:38:18.917 smf-service [DEBUG] [GenericGtpMsg.go:1824] [smf-service.smf-app.sgw] Secondary Rat Data Usage Report Recvd
2021/01/24 11:38:18.917 smf-service [WARN] [IntMethods.go:137] [smf-service.Policy.gen] Qos Flow not found with EBI [8]
2021/01/24 11:38:18.917 smf-service [ERROR] [GenericGtpMsg.go:1853] [smf-service.smf-app.sgw]  Qfi invalid in secRatUsageRpt

Secondary RAT Usage invalid RAT Type

The following example displays the error log for secondary RAT usage with invalid RAT type.

2021/01/24 11:42:21.474 smf-service [DEBUG] [GenericGtpMsg.go:1824] [smf-service.smf-app.sgw] Secondary Rat Data Usage Report Recvd
2021/01/24 11:42:21.474 smf-service [ERROR] [GenericGtpMsg.go:1861] [smf-service.smf-app.sgw]  Rat type invalid in secRatUsageRpt

Secondary RAT Usage with intended PGW set to zero

The following example displays the error log for secondary RAT usage with intended P-GW set to zero (IRPGW:0).

2021/01/24 11:33:10.390 smf-service [DEBUG] [GenericGtpMsg.go:1824] [smf-service.smf-app.sgw] Secondary Rat Data Usage Report Recvd
2021/01/24 11:33:10.390 smf-service [ERROR] [GenericGtpMsg.go:1865] [smf-service.smf-app.sgw]  secRatUsageRpt.IRPGW is false

PRA ID received greater than four

The following example displays the error log when PRA ID received is greater than four.

2021/01/24 14:48:26.085 smf-service [DEBUG] [policy_types.go:659] [smf-service.Policy.gen] praConfig:true for dnn:fast.t-mobile.com
2021/01/24 14:48:26.085 smf-service [DEBUG] [policy_pcf.go:1939] [smf-service.Policy.gen] Added PRA ID: 9388618
2021/01/24 14:48:26.085 smf-service [DEBUG] [policy_pcf.go:1939] [smf-service.Policy.gen] Added PRA ID: 9388608
2021/01/24 14:48:26.085 smf-service [DEBUG] [policy_pcf.go:1939] [smf-service.Policy.gen] Added PRA ID: 8388618
2021/01/24 14:48:26.085 smf-service [DEBUG] [policy_pcf.go:1939] [smf-service.Policy.gen] Added PRA ID: 9388619
2021/01/24 14:48:26.085 smf-service [WARN] [policy_pcf.go:1934] [smf-service.Policy.gen] Max 4 PRAs allowed, ignoring the PRA-ID (8388608) from PCF
2021/01/24 14:48:26.085 smf-service [WARN] [policy_pcf.go:1934] [smf-service.Policy.gen] Max 4 PRAs allowed, ignoring the PRA-ID (8388619) from PCF

2G and 3G network integration in SMF

2G and 3G network integration overview

Table 4. Feature History Table

Feature

Release

Description

2G and 3G session attach and detach procedures over GTPv1

2025.03.0

This features includes details on 2G and 3G session attach and detach support on SMF for v1SGSN. It captures the GTPv1 messages/procedure and information elements that are translated to GTPv2 equivalents.

QoS negotiation for 2G and 3G sessions

2025.03.0

This feature introduces Quality of Service (QoS) negotiation capabilities for 2G and 3G subscribers utilizing the S4-SGSN in SMF. It enables dynamic and automated adjustments to the QoS parameters of the default bearer based on triggers originating from the Home Location Register (HLR) or PCF.

This allows the network to adapt to changing conditions and subscriber needs, optimizing resource utilization and enhancing the user experience.

S4-SGSN session handover and mobility management for 2G and 3G networks

2025.03.0

This feature details the handling of Modify Bearer Requests (MBR) and handover scenarios within the context of 2G and 3G support for S4SGSN in SMF. It outlines the procedures for user location changes, inter-RAT handovers (4G to 3G/2G and 3G/2G to 4G ), intra-RAT handovers (3G SGW handover), and handovers involving dedicated bearers.

This ensure that the sessions are maintained during handovers, minimizing disruption to user applications.

2G and 3G session attach and detach procedures for S4-SGSN

2025.02.0

This feature adds support to the SMF for managing attach and detach functions originating from S4-SGSN (Serving GPRS Support Node). This allows the consolidation of 2G/3G and 4G/5G network control within a single converged core. By integrating the networks, you can simplify the network management and reduce the operational costs.

Commands Introducted:

profile converged-core activated-features 2g3g —This CLI command enables S4-SGSN support for 2G and 3G RAT type in SMF.

Default Settings:Disabled - Configuration Required to Enable

The inclusion of 2G and 3G network intergartion in Converged Core (CC) is to support the full spectrum of radio access technologies such as 2G, 3G, 4G,Wi-Fi and 5G networks on a single environment. This eliminates the need to maintain separate networks for different radio access types.

The 2G and 3G session attach and detach procedures for S4-SGSN feature includes 2G and 3G RAT types in the existing SMF set by leveraging the support of SMF for SBI interfaces. The features and functionalities supported at the SMF for 4G are extented to 2G and 3G networks.

The key capablities of this feature are listed here:

  • GTPv2 protocol support: Implements the necessary GTPv2 protocol handling within the SMF to process attach and detach signaling messages originating from S4-SGSN nodes.

  • Converged core integration: Allows for the management of 2G/3G subscribers within the same SMF instance as 4G/5G subscribers, streamlining network management and reducing the need for separate control plane entities.

  • Inter-RAT mobility: Supports mobility scenarios between 2G/3G and 4G/5G networks, enabling a consistent user experience across different radio access technologies (RATs).

Standard compliance for 2G and 3G network integration with converged core

The 2G and 3G network integration feature complies with the following 3GPP standards for configuring N7 and N40 interfaces and common data types in SMF:

  • 3GPP TS 29.512, Version 17.3.0—For N7 interface

  • 3GPP TS 32.291, Version 17.0.0—For N40 interface

  • 3GPP TS 29.571, Version 17.3.0—For common data types

Prequisites for 2G and 3G network integration with converged core

The prerequistes for 2G and 3G network integration feature in SMF are listed here:

  • Before enabling this feature, the PCF/CHF users need to upgrade to 3GPP Release Version 17 or above versions.

  • You should migrate to N7 or N40 interface from Gx,Gy, and Gz interface for 2G and 3G calls and interaction.

  • Secondary PDR will not be created during 2G and 3G attach, as the handover to 5G network will not be allowed if the UE is attached to 2G or 3G network.

Limitations of 2G and 3G network integration with converged core

Here are the limitations of 2G and 3G network integration feature in SMF:

  • Secondary PDP context (Network or UE) is not supported in this feature.

  • The 2G and 3G networks do not support DHCP/OC/VoGX functionalities that are not supported in SMF for 4G network.

  • The Dual-Connectivity with New Radio (DCNR) is not received in the CSR request from S4-SGSN nodes. Hence, DCNR support is not required in SMF.

  • N10 subscription fetch, subscription to notifications, and registration functionalities are skipped for UTRAN/GERAN attach, as the S4-SGSN/SGSN retrieves the subscription data from HSS/HLR.

Attach and detach procedure call flows for S4-SGSN

The attach and detach procedures are explained through PDN connect call flow and PDN disconnect call flow over S4-SGSN network.

PDN connect over S4-SGSN

This section describes the call flow and stages in PDN connect over S4-SGSN.

Figure 1. PDN connect over S4-SGSN

The given stages describe the interactions between SMF and other NFs for initial attach on GERAN and UTRAN through SMF:

  1. SMF receives CreateSessionRequest notification from SGW. The RAT type in CreateSessionRequest is GERAN for 2G attach and UTRAN for 3G attach.

    The User Location Information (ULI) contains any one of the given values:

    • Routing Area Identification (Rai)

    • Serving Area Identifier (Sai)

    • Cell Global Identification (Cgi)

    • Serving Area Identifier + Routing Area Identification

    • Cell Global Identification + Routing Area Identification

    Refer the Interface level IE information to support S4-SGSN for more information on IE and RAT type values for different notifications.

  2. SMF sends PolicyCreateRequest message to PCF to establish the policy association.

  3. SMF receives PolicyCreateSuccess message from PCF with policy charging and control information.

  4. UE IP address is allocated and SMF sends PolicyUpdateRequest message to PCF with trigger UE_IP_CH.

  5. SMF receives PolicyUpdateSuccess message from PCF.

  6. Based on the charging policies received from PCF, the SMF initiates ChargingDataRequest message towards CHF.

  7. SMF receives ChargingDataSuccess message from CHF and receive these notifications:

    • CC triggers at Session/RG Level

    • Session level Time/Volume Limits

    • Time/Volume Limits at RG level

    • Quota at RG Level

  8. SMF sends N4SessionEstablishmentRequest message towards UPF to relay information related to PDRs, QERs, FARs and URRs.

  9. SMF receives N4SessionEstablishmentSuccess message from UPF.

  10. The SMF sends CreateSessionResponse message to S-GW and includes the bearer information and Tunnel Endpoint Identifier (TEID) for the default bearer.

PDN disconnect over S4-SGSN

This section describes the PDN disconnect over S4-SGSN call flows.

UE-initiated release

The call flow illustrates the UE-initiated release for PDN disconnect over S4-SGSN.

Figure 2. UE-initiated PDN disconnect

The following procedure explains the UE-initiated release for PDN disconnect over S4-SGSN:

  1. SMF receives DeleteSessionRequest message from SGW.

  2. SMF sends N4SessionReleaseRequest message to remove the user plane resources UPF.

  3. SMF receives N4SessionReleaseSuccess message with final usage from UPF.

  4. SMF sends DeleteSessionResponse message to SGW.

  5. SMF sends ChargingReleaseRequest message with final usage to CHF.

  6. SMF receives ChargingReleaseSuccess message from CHF.

  7. SMF sends PolicyDeleteRequest message to PCF to delete the policy association to PCF.

  8. SMF receives PolicyDeleteSuccess message from PCF.

SMF-initiated release

The call flow illustrates the SMF-initiated release for PDN disconnect over S4-SGSN.

Figure 3. SMF-initiated PDN disconnect

The given procedure explains the SMF-initiated release for PDN disconnect:

  1. The SMF-initiated release is triggered using the clear subscriber command.

  2. SMF sends N4SessionModificationRequest message with drop action set in update FAR to UPF.

  3. SMF receives N4SessionModificationSuccess message from UPF.

  4. SMF sends DeleteBearerRequest message to SGW to delete the bearer context.

  5. SMF receives DeleteBearerSuccess message from SGW.

  6. SMF sends N4SessionReleaseRequest message to UPF to remove the user plane resources.

  7. SMF receives N4SessionReleaseSuccess message with final usage from UPF.

  8. SMF sends ChargingReleaseRequest message to CHF with final usage.

  9. SMF receives ChargingReleaseSuccess message from CHF.

  10. SMF sends PolicyDeleteRequest message to PCF to delete the policy association.

  11. SMF receives PolicyDeleteSuccess message from PCF.

Interface level IE information to support S4-SGSN

This section provides information about the IE and RAT type values for notifications from S5/S8, N7, N40, and N4 interfaces.

S5/S8 interface

Here is the set of new enums and corresponding values that are supported on the S5/S8 interface when the control signaling originates from S4-SGSN node in the operator network.

Table 5. S5/S8 interface

Interface S5/S8 messages

IE

Details

Message Create/Modify Session Request

GTPV2_IE_RAT_TYPE

GERAN/UTRAN

Create/Modify/ Delete Session Request

GTPV2_IE_ULI

The User Location Information (ULI) contains any one of the these listed values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

N7 interface

Refer the following IE information for N7 interface messages:

Table 6. N7 interface

Interface N7 messages

IE

Details

Message :: N7 Create Request

SmPolicyContextData- >ServNfId

AnGwAddr for GTPv2 2G/3G and SgsnAddr for GTPv1 2G/3G call

SmPolicyContextData->RatType

GERA/UTRA

SmPolicyContextData->AccessType

3GPP_ACCESS

SmPolicyContextData-> PolicyCtrlReqTriggers

'SCELL_CH', 'SAREA_CH', 'SCNN_CH'

SmPolicyContextData-> UserLocationInfo-> GeraLocation/UtraLocation

The GeraLocation or UtraLocation may contain any one of the these values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

SmPolicyContextData->Suppfeat

The 2G3GIWK flag bit is set to 1, if the PCF release version is greater than and equal to 17.3.0 and the 2g3g CLI is configured.

Message :: N7 Update Request

SmPolicyUpdateContextData ->ServNfId

AnGwAddr for GTPv2 2G/3G and SgsnAddr for GTPv1 2G/3G call

SmPolicyUpdateContextData ->RatType

GERA/UTRA

SmPolicyContextData-> PolicyCtrlReqTriggers

'SCELL_CH', 'SAREA_CH', 'SCNN_CH'

SmPolicyUpdateData->ServNfId

SmPolicyUpdateData-> UserLocationInfo-> GeraLocation/UtraLocation

The GeraLocation or UtraLocation contains any one of the these values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

Message :: N7 Delete Request

SmPolicyDeleteData-> UserLocationInfo-> GeraLocation/UtraLocation

The GeraLocation or UtraLocation contains any one of the these values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

N40 interface

Refer the following IE information for N40 interface messages:

Table 7. N40 interface

Interface N40 messages

IE

Details

Message :: ChargingDataRequest

PDUSessionInformation-> RatType

GERA/UTRA

nfConsumerIdentification-> nodeFunctionality

SMF

PDUSessionInformation ->servingNetworkFunctionID -> nodeFunctionality

SGW for GTPv2 2G/3G and SGSN for GTPv1 2G/3G call

UserLocationInfo-> GeraLocation/UtraLocation

The GeraLocation or UtraLocation may contain any one of the these values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

Message :: ChargingDataResponse

[]triggers

Trigger Type CGI_SAI_CHANGE RAI_CHANGE

MultiUnitInformation-> []triggers

Trigger Type CGI_SAI_CHANGE RAI_CHANGE

Message :: ChargingReleaseRequest

PDUContainerInformation-> RatType

GERA/UTRA

PDUContainerInformation-> ServingNodeID-> nodeFunctionality

SGW for GTPv2 2G/3G and SGSN for GTPv1 2G/3G call

PDUSessionInformation ->servingNetworkFunctionID -> nodeFunctionality

SGW for GTPv2 2G/3G and SGSN for GTPv1 2G/3G call

PDUSessionInformation-> RatType

GERA/UTRA

nfConsumerIdentification-> nodeFunctionality

SMF

UserLocationInfo-> GeraLocation/UtraLocation

The GeraLocation or UtraLocation may contain any one of the these values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

N4 interface

Refer the following IE information for N4 interface messages:

Table 8. N4 interface

Interface N4

IE

Details

PFCP Establishment Request

PFCP Modification Request

Subscriber Params->Rat Type

The RAT Type value can be either 1 or 2.

1 - UTRAN

2 - GERAN

Subscriber Params->Uli

The User Location Information (ULI) contains any one of the these listed values:

  • Rai

  • Sai

  • Cgi

  • Cgi + Rai

  • Sai + Rai

Subscriber Params->Sgsn address

The SGSN address can be either IPv4/IPv6.

Subscriber Params->Ggsn address

The GGSN address can be either IPv4/IPv6.

Create_FAR ->Outer Header Creation ->Teid

The TEID value contains the SGW GTP-U TEID.


Note


The User Location Information - Location Area Identifier (Lai) is not supported in S5/S8, N7, N40, and N4 interfaces.


Enable S4-SGSN for 2G and 3G RAT type

This configuration allows to enable the S4-SGSN support for 2G and 3G RAT type in SMF.

Procedure

Step 1

Enter the converged core profile name converged-core <name> in congifuration mode.

config
profile converged-core <name>

Step 2

Enter the 2g3g flag to enable S4-SGSN in SMF and end the command.

config
   profile converged-core <name>
   activated-features 2g3g
end

Here is the sample configuration:

[smf] smf(config)# profile converged-core cc activated-features ?
Possible completions:
  2g3g               This flag enables the support for 2G 3G RAT on SMF
  upf-blocklisting   This flag enables upf blocklist feature 
[smf] smf(config)# profile converged-core cc activated-features 2g3g 
Tue Mar  4  13:28:27.850 UTC+00:00
[smf] smf(config-converged-core-cc)#

Note

 

To disable the configuration, use the given syntax:

config
   profile converged-core <name>
   [no] activated-features 2g3g
end

If the configuration is disabled, the S4-SGSN (v2) messages are rejected with appropriate System Failure error code and gtpc_app_total_unexpected_gtpc_msg_events metric is incremented.

Step 3

Optional: Run the show running-config profile converged-core cc CLI command to verify if the 2g3g flag is enabled.

[smf] smf# show running-config profile converged-core cc
Tue Mar  4  13:30:51.799 UTC+00:00
profile converged-core cc
 supported-features [ rolling-upgrade-all ]
 activated-features 2g3g
exit

Configure N40 charging compliance version

This procedure allows to configure the 3GPP Specification TS 32.291 of Version 17.0.0 in N40 charging for 2G and 3G sessions in SMF.

Procedure

Step 1

Enter the compliance profile name in configuration mode.

config
profile compliance < compliance profile name>

Step 2

Enter the nchf-convergedcharging version as 17.0.0 and end the command.

config
profile compliance < compliance profile name>
service nchf-convergedcharging version spec 17.0.0
end

Here is the sample configuration:


[smf] smf(config-compliance-comp1)# service nchf-convergedcharging version spec ?
Description: 3gpp nchf-convergedcharging Spec version number - 15.0.0 [default] 
Possible completions:
  [17.0.0] 15.0.0  15.1.0  15.2.1  15.3.0  15.3.0.custom  15.3.0.std  15.4.0  16.8.1  17.0.0
[smf] smf(config-compliance-comp1)# service nchf-convergedcharging version spec 17.0.0
Mon Oct  21 12:19:46.838 UTC+00:00
[smf] smf(config-service-nchf-convergedcharging)# 

Step 3

Optional: Run the show running-config profile compliance comp1 service nchf-convergedcharging CLI command to verify the charging compliance version for N40 interface.

[smf] smf# show running-config profile compliance comp1 service nchf-convergedcharging
Wed Oct  23 11:49:52.490 UTC+00:00
profile compliance comp1
 service nchf-convergedcharging
  version uri v1
  version full 1.0.0
  version spec 17.0.0
 exit
exit
[smf] smf#


Configure N7 policy compliance version

This procedure allows to configure the 3GPP Specification TS 29.512 of Version 17.3.0 in N7 Policy for 2G and 3G Sessions in SMF.

Procedure

Step 1

Enter the compliance profile name in configuration mode.

config
profile compliance < compliance profile name>

Step 2

Enter the nchf- smpolicycontrol version as 17.3.0 and end the command.

config
profile compliance < compliance profile name>
service nchf- smpolicycontrol version spec 17.3.0
end

Here is the sample configuration:


[smf] smf(config-compliance-comp1)# service npcf-smpolicycontrol version spec ?
Description: 3gpp npcf-smpolicycontrol Spec version number - 15.2.0 [default] 
Possible completions:
  [17.3.0]  15.0.0  15.2.0  15.4.0  16.10.0  17.3.0
[smf] smf(config-compliance-comp1)# service npcf-smpolicycontrol version spec 17.3.0
Mon Oct  21 12:21:22.960 UTC+00:00
[smf] smf(config-service-npcf-smpolicycontrol)

Step 3

Optional: Run the show running-config profile compliance comp1 service npcf-smpolicycontrol CLI command to verify the policy compliance version for N7 interface.

[smf] smf# show running-config profile compliance comp1 service npcf-smpolicycontrol
Wed Oct  23 11:49:01.841 UTC+00:00
profile compliance comp1
 service npcf-smpolicycontrol
  version uri v1
  version full 1.0.0
  version spec 17.3.0
 exit
exit

Show commands and clear session commands for 2G and 3G sessions

This section provides information on the show commands and clear session commands associated with 2G and 3G network intergation feature in SMF.

Display subscriber information for 3G session with UTRAN RAT type

Here is the sample output for show subscriber CLI command for 3G session with UTRAN RAT type:

show subscriber nf-service smf supi imsi-123456789012345 full


  "subResponses": [
    {
      "status": true,
      "genericInfo": {
        "pduState": "pduState_None",
        "supi": "imsi-123456789012345",
        "pei": "imei-123456786666660",
        ...
       "uetimeZone": "+00:15+1",
        "allocatedIp": "12.0.0.1",
        "alwaysOn": "None",
        "dcnr": "None",
        "wps": "Non-Wps Session",
        "ratType": "UTRA",
        "ueType": "NR Capable UE",
        "sessTimeStamp": "2025-03-03 12:34:35.409932765 +0000 UTC",
        ...
     "ipAllocationBy": "Dynamic",
        "anType": "3GPP_ACCESS",
        "utranLocation": {
          "cgi": {
            "mcc": "123",
            "mnc": "456",
            "lac": "04d2",
            "cellId": "0004"
          },
          "ueLocationTimestamp": "2025-03-03T12:34:35Z"
        },
        "initialRatType": "UTRA"
      },
      "policySubData": {
        "TotalDynamicRules": 1,
        "TotalFlowCount": 1,
        "TotalNonGBRFlows": 1,
       
    },
    ...
     "access3GSubData": {
        "localTeid": 2097154,
        "lbi": 5,
        "bearerContexts": [
          {
            "ebi": 5,
            "defBrr": true,
            "dlFteid": {
              "teid": 1647,
              "ipaddr": "10.1.34.62"
            }
          }
        ],
   "AnGwAddr": {  For GTPv2 3G call 
    "anGwIpv4Addr": "10.1.0.227"
   }

   "sgsnAddr": {  For GTPv1 3G call 
   "sgsnIpv4Addr": "10.1.0.227"
  }
        "gtpVersion": "GtpV2"
      }
    }
  ]
}

The output for 2G session is similar with GERAN as RAT type.

Display session count information

Use the show subscriber count CLI command to display the number of active sessions for a specific RAT type. Here is an example:

show subscriber count nf-service smf rat utran

subscriber-details 
{
  "sessionCount": 1
}

Note


The RAT type based show and clear session options are enhanced for 2G and 3G sessions as given here:

  • show subscriber nf-service smf rat geran/utran​

  • clear subscriber nf-service smf rat utran/geran


For clear session, the options applicable for 4G sessions such as IMSI, MSID, RuleBase and so on are applicable for 2G and 3G sessions as well.

S4-SGSN MBR and handover procedures for 2G and 3G support

This feature enhances the converged core to provide mobility and session continuity for UE operating in 2G (GERAN) and 3G (UTRAN) networks. It focuses on the handling of Modify Bearer Requests (MBRs) to manage user location updates and supports various handover scenarios to ensure uninterrupted service as users move between different RATs.

Following is the list of MBR and handover procedures for S4-SGSN in SMF:

  • User location update handling (MBR)

  • Inter-RAT handover support (4G/LTE <=> 2G/3G)

  • Dedicated bearer handling

  • Intra-RAT handover support (2G/3G)

Restricted S4-SGSN handover

Here is the list of restricted S4-SGSN handover support in SMF:

  • If the UE attach is in 2G/3G access type, the direct and indirect handover to 5G and vice versa are rejected with a service not supported reason. The given handovers are not supported:

    • 2G/3G -> 5G

    • 5G->2G/3G

    • 5G->4G->2G/3G

    • 2G/3G->4G->5G

  • Direct handover from 2G/3G to Wi-Fi and vice versa are not supported.Indirect handover such as, 2G/3G->4G->Wi-Fi and vice versa are supported.

  • The SMF will disregard the handover indication flag in the ModifyBearerRequest when processing 2G/3G handovers.

  • Handover to 2G/3G is rejected, if the 2G/3G CLI is not enabled during attach procedure.

  • Handover to 2G/3G is rejected, if the 4G session is established in previous release 2025.2.0 version.

MBR procedure for user location change

This call flow illustrates the MBR procedure for user location change in S4-SGSN.

Workflow
Figure 4. MBR for ULI change

The following procedure explains the step by step process of MBR in SMF:

  1. After successful attach of 2G/3G in SMF, the SMF receives ModifyBearerRequest message with modified cgi/rai/sai values.

  2. SMF sends ModifyBearerResponse message to SGW.

  3. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS having updated cgi/rai/sai.

    • PFCP_IE_QUERY_URR sent for URRs with trigger configured.

  4. SMF receives N4ModificationResponse message with usage report.

  5. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as USER_LOCATION_CHANGE.

    • MultipleUnitUsage with GERA/UTRA type.

    • PDUSessionChargingInformation with GERA/UTRA RAT type.

  6. SMF receives ChargingDataUpdateResponse message from CHF.

  7. SMF sends PolicyUpdateRequest message with SAREA_CH.

  8. SMF receives PolicyUpdateResponse message from PCF.


Note


The call flow is similar for 2G RAT type.


S4-SGSN inter-RAT handover procedures

This section describes handovers between 4G and 2G/3G, with home and roaming scenarios.

The following procedures are covered as a part of inter-RAT handover in S4-SGSN:

  • 4G homer to 3G roamer handover

  • 3G homer to 4G roamer handover

  • 4G roamer to 3G homer handover

  • 3G roamer to 4G homer handover

4G homer to 3G roamer

This call flow illustrates the inter-Rat handover for 4G homer to 3G roamer scenario in S4-SGSN.

Workflow
Figure 5. 4G homer to 3G roamer

The following procedure explains the step by step process of inter-RAT handover for 4G homer to 3G roamer in SMF:

  1. After successful attach of 4G in SMF, the SMF receives ModifyBearerRequest message with the following values:

    • Visitor PLMN in Serving NW

    • RAT Type UTRA

    • Modified target GTP-U TeID

  2. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS with ratType = 1(UTRAN) and roaming_status = 4(ROMER).

    • Create N9 and S5 PDRs.

    • Delete N3 and S5 PDRs.

    • Update DL S5 FAR with forw action set and target TeID in outer_header_creation.

    • Query_interface for online and offline URRs.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as RAT_CHANGE.

    • MultipleUnitUsage with EUTRA RAT type.

    • PDUSessionChargingInformation with UTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

  6. SMF sends PolicyUpdateRequest message with repPolicyCtrlReqTriggers as RAT_TY_CH and RAT type UTRA.

  7. SMF receives PolicyUpdateResponse message from PCF.


Note


The call flow is similar for 4G homer to 2G roamer scenario where RAT type will be as GERA for 2G network.


3G homer to 4G roamer

This call flow illustrates the inter-Rat handover for 3G homer to 4G roamer scenario in S4-SGSN.

Workflow
Figure 6. 3G homer to 4G roamer

The following procedure explains the step by step process of inter-RAT handover for 3G homer to 4G romer in SMF:

  1. After successful attach of 4G in SMF, the SMF receives ModifyBearerRequest message with the following values:

    • Visitor PLMN in Serving NW

    • RAT Type EUTRA

    • Modified target GTP-U TeID

  2. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS with ratType = 1(UTRAN) and roaming_status = 4(ROMER).

    • Delete S5 UL PDRs

    • Re-create S5 UL PDRs

    • Update DL S5 FAR with forw action set and target TeID in outer_header_creation.

    • Query_interface for online and offline URRs.

    The secondary PDR is not created during 3G attach.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as RAT_CHANGE.

    • MultipleUnitUsage with UTRA RAT type.

    • PDUSessionChargingInformation with EUTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

  6. SMF sends PolicyUpdateRequest with repPolicyCtrlReqTriggers as RAT_TY_CH and RAT type UTRA.

  7. SMF receives PolicyUpdateResponse message from PCF.


Note


The call flow is similar for following cases with corresponding RAT type and target roaming status.

  • 2G homer to 4G roamer

  • 2G homer to 3G roamer

  • 3G homer to 2G roamer


4G roamer to 3G homer

This call flow illustrates the inter-Rat handover for 4G roamer to 3G homer scenario in S4-SGSN.

Workflow
Figure 7. 4G roamer to 3G homer

The following procedure explains the step by step process of inter-RAT handover for 4G roamer to 3G homer in SMF:

  1. After successful attach of 4G in SMF, the SMF receives ModifyBearerRequest message with the following values:

    • Homer PLMN in Serving NW

    • RAT Type UTRA

    • Modified target GTP-U TeID

  2. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS with ratType = 1(UTRAN) and roaming_status = 1(HOMER).

    • Create N3 and S5 PDRs.

    • Delete N9 and S5 PDRs.

    • Update DL S5 FAR with forw action set and target TeID in outer_header_creation.

    • Query_interface for online and offline URRs.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as RAT_CHANGE.

    • MultipleUnitUsage with EUTRA RAT type.

    • PDUSessionChargingInformation with UTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

  6. SMF sends PolicyUpdateRequest with repPolicyCtrlReqTriggers as RAT_TY_CH and RAT type UTRA.

  7. SMF receives PolicyUpdateResponse message from PCF.


Note


The call flow is similar for 4G roamer to 2G homer scenario where RAT type will be as GERA for 2G network.


3G roamer to 4G homer

This call flow illustrates the inter-Rat handover for 3G roamer to 4G homer scenario in S4-SGSN.

Figure 8. 3G roamer to 4H homer

The following procedure explains the step by step process of inter-RAT handover for 3G roamer to 4G homer in SMF:

  1. After successful attach of 3G in SMF, the SMF receives ModifyBearerRequest message with the following values:

    • Homer PLMN in Serving NW

    • RAT Type EUTRA

    • Modified target GTP-U TeID

  2. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS with ratType = 6(UTRAN) and roaming_status = 1(HOMER).

    • Delete S5 UL PDRs.

    • Re-create S5 UL PDRs

    • Update DL S5 FAR with forw action set and target TeID in outer_header_creation.

    • Query_interface for online and offline URRs.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as RAT_CHANGE.

    • MultipleUnitUsage with UTRA RAT type.

    • PDUSessionChargingInformation with EUTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

  6. SMF sends PolicyUpdateRequest with repPolicyCtrlReqTriggers as RAT_TY_CH and RAT type EUTRA.

  7. SMF receives PolicyUpdateResponse message from PCF.


Note


The call flow is similar for 2G roamer to 4G homer scenario where RAT type will be as GERA for 2G network.


Handover procedure with dedicated bearer in S4-SGSN

This call flow illustrates the handover procedure with dedicated bearer for 4G homer to 3G roamer scenario in S4-SGSN.

Workflow
Figure 9. Dedicated bearer handover for 4G homer to 3G roamer

The following procedure explains the step by step process of handover procedure with dedicated bearer for 4G homer to 3G roamer scenario in SMF:

  1. After successful attach with dedicated bearer of 4G in SMF, the SMF receives ModifyBearerRequest message with the following values:

    • Visitor PLMN in Serving NW

    • RAT Type UTRA

    • Modified target GTP-U TeID

    • Bearer list with default and dedicated bearer

  2. SMF sends N4ModificationRequest message with the following values:

    • PFCP_IE_SUB_PARAMS with ratType = 1(UTRAN) and roaming_status = 4(ROMER).

    • Create N9 and S5 PDRs for default bearer.

    • Delete N3 and S5 PDRs for default bearer.

    • Update DL S5 FAR for default bearer with forw action set and target TeID in outer_header_creation.

    • Query_interface for online and offline URRs.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as RAT_CHANGE.

    • MultipleUnitUsage with EUTRA RAT type.

    • PDUSessionChargingInformation with UTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

  6. SMF sends PolicyUpdateRequest message with repPolicyCtrlReqTriggers as RAT_TY_CH and RAT type UTRA.

  7. SMF receives PolicyUpdateResponse message from PCF.


Note


In this call flow,

  • If the ModifyBearerRequest message is received with only default bearer in bearer list, the default bearer is processed and dedicated bearer is removed by sending delete PDR,QER,FAR,URR in N4ModificationRequest message.

  • If only dedicated bearer is received, the MBR is rejected.

The call flow is similar for 4G homer with dedicated bearer to 2G roamer scenario where RAT type will be as GERA for 2G network.


Intra-RAT handover for S4-SGSN

The call flow illustrates the SGW handover in 3G network.

Workflow
Figure 10. SGW handover in 3G

The following procedure explains the step by step process of SGW handover for 3G network in SMF:

  1. After successful attach of 3G in SMF, the SMF receives Modify Bearer Request message with Target SGW GTP-U teid and IP address values.

  2. SMF sends N4ModificationRequest message with the following values:

    • Update DL S5 FAR with forw action set and target SGW teid and IP address in outer_header_creation.

    • Query_interface for online and offline URRs.

  3. SMF receives N4ModificationResponse message with usage report.

  4. SMF sends ChargingDataUpdateRequest message to CHF with the following values:

    • TriggerType as SERVING_NODE_CHANGE.

    • MultipleUnitUsage with UTRA RAT type.

    • PDUSessionChargingInformation with UTRA RAT type.

  5. SMF receives ChargingDataUpdateResponse message from CHF.

Dynamic QoS Modification for S4-SGSN on Converged Core

This feature introduces QoS negotiation capabilities for 2G and 3G subscribers using the S4-SGSN within converged core. It enables dynamic and automated adjustments to the QoS parameters of the default bearer based on triggers originating from HLR or PCF.

The key functionalites of QoS modification feature includes:

  • HLR-initiated QoS modification

  • PCF-inititated QoS modification

Limitations of QoS negotiation

Here are the limitations of QoS negotiation for default bearer:

  • HLR or PCF initiated QoS modification for default bearer is allowed only for QCI/ARP change or Sess-AMBR change. Other parameters cannot be modified.

  • Dedicated bearer is not supported for 2G/3G sessions and hence, QoS negotiation for dedicated bearer is not applicable.

  • The non-standard QCI is supported for PCF-initiated modification. It is not for supported for HLR-initiated modification.

HLR-inititated QoS modification

Summary

This call flow illustrates the HLR-inititated QoS modification process in SMF.

Figure 11. HLR-inititated QoS modification
Workflow

The following procedure consists of step by step process for HLR-inititated QoS modification in SMF:

  1. The S4-SGSN sends a Modify Bearer Command to the SGW in response to HLR-initiated QoS parameter updates, with support restricted to default bearer QoS changes. This process supports only default bearer QoS changes.

  2. SMF sends Npcf_SMPolicyControl_Update message to PCF with SESS_AMBR or QOS_CH values.

    • For QoS change, SMF includes the DEF_QOS_CH value within the repPolicyCtrlReqTriggers attribute and the new subscribed default QoS within the subsDefQos attribute.

    • For Sess-AMBR change, SMF includes the SE_AMBR_CH within the repPolicyCtrlReqTriggers attribute and the new Session-AMBR within the subsSessAmbr attribute.

  3. PCF provisions the new authorized session AMBR and authorized default QoS to the SMF in the response.

  4. SMF sends Update Bearer Request message to SGW with modified APN-AMBR, and/or EPS Bearer QoS if the QCI/ARP value is changed.

  5. After receiving a successful Update Bearer Response message from S-GW, SMF triggers the N4 Modification with Update-PDR and/or Update-QER values.

  6. If the bearer modification fails, the SMF takes action based on the Failure Handling Type (FHT).

  7. The existing smf_service_stats metrics with procedure_type mme_req_ded_brr_mod and appropriate rat_type are pegged for this scenario, similar to the 4G session.


Note


The DEF_QOS_CH and SE_AMBR_CH PCF triggers are sent during HLR-initiated QoS modification as indicated. However, they are not supported in any other scenarios.


PCF-inititated QoS modification

This call flow illustrates the PCF-inititated QoS modification process in SMF.

Workflow
Figure 12. PCF-inititated QoS modification

The following procedure consists of step by step process for PCF-inititated QoS modification in SMF:

  1. The PCF-initiated notification update for QoS parameters are supported for default bearer.

    When the SMF receives notification update from PCF, SMF sends Update Bearer Request message to SGW with modified APN-AMBR value, and/or EPS Bearer QoS valuse if the QCI/ARP is changed.

  2. After receiving a successful Update Bearer Response message from S-GW, SMF triggers N4 Modification with Update-PDR and/or Update-QER values.

  3. If a bearer modification fails, the SMF takes action based on the Failure Handling Type (FHT).


Note


For 4G Sessions, SMF doesn’t send any notification to PCF upon UBR or N4 failure. Same behaviour is applied in 2G/3G sessions for both PCF-initiated and HLR-initiated QoS modification.


S4-SGSN PCF-inititated modification

Workflow

In S4-SGSN PCF-inititated modification, the PCF-initiated notification update is supported for default bearer along with the existing 4G implementation. New ProcedureTypes are added for 2g/3g procedures in EventTrace. dedicated bearer operations are not supported for 2g/3g

The following Procedure Failure LogTags are added:

  • 3gbrrmod-procfailure

  • 2gbrrmod-procfailure

The Dedicated bearer creation/modification/deletion is not supported for 2G/3G sessions. SMF rejects any addition of PCC rule that requires creation of dedicated bearer as given in the following illustration.

Dedicated bearer rejection handling

This call flow illustrates the dedicated bearer rejection handling in SMF.

Figure 13. S4-SGSN PCF-inititated modification

When the dedicated bearer creation is rejected, HTTP status code 400 is sent with RuleReport containing failure code as MAX_NR_QoS_Flow.


Note


  1. The given call flow for dedicated bearer rejection handling illustrates a scenario with SmPolicyUpdateNotification message from PCF. Similar rejection handling is done if the PCF sends PccRules value for a new QoS flow such as a new dedicated bearer in SmPolicyCreateResponse or SmPolicyUpdateResponse message. In this case, the SmPolicyUpdateReq message with RuleReports value is triggered.

    • When the new PccRules are received in SmPolicyCreateRsp/ SmPolicyUpdateResponse message during PDN Setup (Piggy-back Dedicated Bearer scenario), rule reports are triggered after PDN setup is complete.

  2. During SmPolicyUpdateNotification, if the expedite CLI is enabled for PCF response, then these RuleReports are sent in SmPolicyUpdateReq message instead of SmPolicyUpdateNotificationResp message.


The existing smf_service_stats with procedure type pcf_req_ded_brr_create is pegged with failures status and reason as oper_not_supported_in_rat. Label qos_5qi containing QCI values is not populated in such reject scenarios.

Attach and detach procedures for GTPv1 SGSN

The feature describes the support for attach and detach procedures for GTPv1 SGSN. The GTPv1 messages and information elements are translated to their GTPv2 equivalents for processing by the SMF.

As part of the 2G and 3G support, SMF needs the capability to support Gn interface. SMF receives GTPv1 messages on the same interface (service IP) exposed as S5.

In this feature, the following GTPv1 messages are supported:

  • Create PDP Context Request

  • Create PDP Context Response

  • Delete PDP Context Request

  • Delete PDP Context Response

The attach and detach procedures are explained through PDN connect call flow and PDN disconnect call flow over SGSN.

  • PDN connect over SGSN

  • PDN disconnect over SGSN

PDN connect over SGSN

This section describes the call flow and stages in PDN connect over SGSN.

Workflow
Figure 14. PDN connect over SGSN

The given stages describe the interactions between SMF and other NFs for initial attach on GERAN and UTRAN through SMF:

  1. SMF receives Create PDP Context Request message from SGSN with the following values:

    • RAT types are GERAN for 2G attach and UTRAN for 3G attach

    • SGSN Control

    • Data TEID

    The ULI contains any one of the following values:

    • Routing Area Identification (Rai)

    • Serving Area Identifier (Sai)

    • Cell Global Identification (Cgi)

    • Serving Area Identifier + Routing Area Identification

    • Cell Global Identification + Routing Area Identification

  2. SMF sends PolicyCreateRequest message to PCF to establish policy association.

  3. SMF receives PolicyCreateSuccess message from PCF with policy charging and control information.

  4. UE IP address is allocated and SMF sends PolicyUpdateRequest to PCF with UE_IP_CH trigger.

  5. SMF receives PolicyUpdateSuccess message from PCF.

  6. Based on the charging policies received from PCF, the SMF initiates ChargingDataRequest message towards CHF.

  7. SMF receives ChargingDataSuccess message from CHF and get the following values:

    • CC triggers at Session/RG Level

    • Session level Time/Volume Limits

    • Time/Volume Limits at RG level

    • Quota at RG Level

  8. SMF sends N4SessionEstablishmentRequest message towards UPF to relay information related to PDRs, QERs, FARs and URRs.

  9. SMF receives N4SessionEstablishmentSuccess message from UPF.

  10. SGSN receives Create PDP Context Response (Bearer Control Mode value as 2) from SMF.

PDN disconnect over SGSN

This section describes the PDN disconnect over S4-SGSN call flows.

UE-initiated release for SGSN

The call flow illustrates the UE-initiated release for PDN disconnect over SGSN.

Workflow
Figure 15. UE initiated PDN disconnect
Summary

The following procedure explains the UE-initiated release for PDN disconnect over SGSN:

  1. SMF receives Delete PDP Context Request message from SGSN.

  2. SMF sends N4SessionReleaseRequest message to UPF to remove the user plane resources.

  3. SMF receives N4SessionReleaseSuccess message with final usage from UPF.

  4. SGSN receives Delete PDP Context Response message from SMF.

  5. SMF sends ChargingReleaseRequest message to CHF with final usage.

  6. SMF receives ChargingReleaseSuccess message from CHF.

  7. SMF sends PolicyDeleteRequest message to PCF to delete the policy association.

  8. SMF receives PolicyDeleteSuccess message from PCF.

SMF-initiated release for SGSN

The call flow illustrates the SMF-initiated release for PDN disconnect over SGSN.

Workflow
Figure 16. SMF-initiated PDN disconnect

The following procedure explains the SMF-initiated release for PDN disconnect:

  1. The SMF-initiated release is triggered using the clear subscriber command. SMF sends N4SessionModificationRequest message with drop action set in update FAR.

  2. SMF receives N4SessionModificationSuccess message.

  3. SMF sends the Delete PDP Context Request message to SGSN.

  4. SMF receives the Delete PDP Context Response message from SGSN.

  5. SMF sends N4SessionReleaseRequest message to UPF to remove the user plane resources.

  6. SMF receives N4SessionReleaseSuccess message with final usage from UPF.

  7. SMF sends ChargingReleaseRequest message to CHF with final usage.

  8. SMF receives ChargingReleaseSuccess message from CHF.

  9. SMF sends PolicyDeleteRequest message to PCF to delete the policy association.

  10. SMF receives PolicyDeleteSuccess message from PCF.

Show command output for GTPv1 2G and 3G sessions

Sample output for show command

Here is the sample output for show subscriber CLI command with GTPv1 message information:


show subscriber supi imsi-123456789012345 nf-service smf full | exclude subscriber-details

{
  "subResponses": [
    {
      "status": true,
      "genericInfo": {
        "pduState": "pduState_None",
        "supi": "imsi-123456789012345",
        "pei": "imei-123456786666660",
        "pduSessionId": 69,
        "pduSesstype": "Ipv4PduSession",
        "accessType": "3GPP_ACCESS",
        "dnn": "intershat",
        "plmnId": {
          "mcc": "123",
          "mnc": "456"
        },
        "sScMode": 1,
        "uetimeZone": "+00:15",
        "allocatedIp": "12.0.4.0",
        "alwaysOn": "None",
        "dcnr": "Enabled",
        "wps": "Non-Wps Session",
        "ratType": "UTRA",
        "ueType": "4G Capable And NR Unknown UE",
        "sessTimeStamp": "2025-07-14 06:40:23.582495295 +0000 UTC",
        "callDuration": "5.743140999s",
        "ipPool": "poolv4",
        "commonId": 66,
        "linkedEbi": 5,
        "snssai": {
          "sd": "Abf123",
          "sst": 2
        },
        ...
        "ipAllocationBy": "Dynamic",
        "anType": "3GPP_ACCESS",
        "utranLocation": {
          "cgi": {
            "mcc": "123",
            "mnc": "456",
            "lac": "04d2",
            "cellId": "0004"
          },
          "rai": {
            "mcc": "123",
            "mnc": "456",
            "lac": "04d2",
            "rac": "22"
          },
          "ueLocationTimestamp": "2025-07-14T06:40:23Z"
        },
        "initialRatType": "UTRA"
      },
      ...    }
        ],
        "qosFlow": [
          {
            "qfi": 1,
            "GBRFlow": "False",
            "bindingParameters": {
              "x5Qi": 9,
              "arp": {
                "preemptCap": "NOT_PREEMPT",
                "preemptVuln": "PREEMPTABLE",
                "priorityLevel": 1
              },
              ...
            "startTime": "2025-07-14T06:40:23Z",
            "rulebase": "rba_charging_staticonly_offline",
            "chargingDisabled": "false",
            "dropTraffic": "false",
            "gtppGrp": "group1",
            "profileName": "chgprf1",
            "accountingEnabled": "false",
            "n40ChargingEnabled": "true",
            "qbcChargingEnabled": "false",
            "offlineConverted": "false",
            "chfGroupId": "CHF-dnn=intershat;",
            "chfChargDataRef": "1111",
            "bearerInctCharg": "false",
            "gyChargingEnabled": "false",
            "gzChargingEnabled": "false"
          }
        ]
      },
      ...
  "upfSeid": "17293822569102704642",
        "TotalNumberOfPdrs": "2 (Ul:1 Dl:1)",
        "TotalNumberOfFars": 2,
        "TotalNumberOfQers": 2
      },
      "access3GSubData": {
        "localTeid": 66,
        "lbi": 5,
        "bearerContexts": [
          {
            "ebi": 5,
            "defBrr": true,
            "dlFteid": {
              "teid": 1655,
              "ipaddr": "192.168.7.61"
            }
          }
        ],
        "sgsnAddr": {
          "sgsnIpv4Addr": "172.10.1.26"
        },
        "gtpVersion": "GtpV1"
      }
    }
  ]
}

Sample output for monitor subscriber CLI command

This section provides information on the sample output for monitor subscriber CLI command associated with the GTPv1 messages in SMF.

Create PDP Context Request message output

Here is the sample output that dispalys Create PDP Context Request message information in monitor subscriber CLI command:

Subscriber Id: imsi-123456789012345
      Timestamp: 2025/02/27 11:37:03.690314
    Message: S5 S8 Create PDP Context Request
    Description: Create PDP Context Request Message displayed after decoding into Create Session Request Message Proto

      Source: 172.00.0.00

      Destination: 10.1.00.000

      PAYLOAD:
        S5 S8 Create PDP Context Request: 

            S5 S8 Create PDP Context Request: 

                Version: 1
	     ...
                MsgType: 
                   Create_Session_Request: 
                       IMSI: 123456789012345
Create PDP Context Response message output

Here is the sample output that dispalys Create PDP Context Response message information in monitor subscriber CLI command:

Subscriber Id: imsi-123456789012345
         Timestamp: 2025/02/27 11:37:03.939684
      Message: S5 S8 Create PDP Context Response
      Description: Create PDP Context Response Message displayed after decoding into Create Session Response Message Proto

      Source: 10.0.00.000
      Destination: 172.00.0.00
PAYLOAD:
       S5 S8 Create PDP Context Response: 
          S5 S8 Create PDP Context Response: 
                Version: 1
	    ...
             MsgType: 

                    Create_Session_Response: 
                     Cause: 
                         Cause_Value: 16
Delete PDP Context Request message output

Here is the sample output that dispalys Delete PDP Context Request message information in monitor subscriber CLI command:

Subscriber Id: imsi-123456789012345
      Timestamp: 2025/02/27 11:37:14.149143
    Message: S5 S8 Delete PDP Context Request
    Description: SGSN Initiated Delete PDP Context Request Message 
displayed after decoding into Delete Session Request Message Proto
      Source: 172.00.0.00

      Destination: 10.1.00.000

      PAYLOAD:
        S5 S8 Delete PDP Context Request: 

            S5 S8 Delete PDP Context Request: 

                Version: 1
	     ...
                MsgType: 
                   Delete_Session_Request: 
                       Linked_EBI:
                            Value: 6
Delete PDP Context Response message output

Here is the sample output that dispalys Delete PDP Context Response message information in monitor subscriber CLI command:

Subscriber Id: imsi-123456789012345
      Timestamp: 2025/02/27 11:37:14.187506
    Message: S5 S8 Delete PDP Context Response
    Description: SGSN Initiated Delete PDP Context Response Message 
displayed after decoding into Delete Session Response Message Proto
      Source: 172.00.0.00

      Destination: 10.1.00.000

      PAYLOAD:
        S5 S8 Delete PDP Context Response: 

            S5 S8 Delete PDP Context Response: 

                Version: 1
	     ...
                MsgType: 
                   Delete_Session_Response: 
                       Cause:
                           Cause_Value: 16

Statistics for 2G and 3G sessions

Use these bulk statistics for monitoring, analyzing, and troubleshooting 2G and 3G sessions.

Table 9. Metrics for 2G and 3G sessions

Metrics

Label Information

smf_gtpc_msg_stats

This counter is incremented for every access request message received from SGW.

  • app_name < app_name>

  • cluster <cluster>

  • data_center <data_center>

  • dnn <dnn>

  • gr_instance_id < gr_instance_id>

  • instance_id <instance_id>

  • message_type <message_name>

  • qos_5qi <qci>

  • rat_type <rat_type>

    The rat_type value shall be either GERA or UTRA for 2G/3G.

  • smf_service_stats

  • smf_session_stats

  • chf_message_stats

  • chf_session_stats

  • policy_msg_processing_status

  • policy_pdu_flows_total

  • smf_datacheck_stats

  • smf_disconnect_stats

  • smf_service_counters

  • smf_service_resource_mgmt_stats

  • smf_restep_http_msg_total

rat_type <rat_type>

The rat_type value is either GERA or UTRA for 2G and 3G calls.

smf_session_counters

The fourg_only_ue label is marked as fourg_only_ue:unknown when the SessionID is greater than or equal to 64 for 2G and 3G sessions.

cdl show sessions summary

The fourg_only_ue label is marked as fourg_only_ue:unknown when the SessionID is greater than or equal to 64 for 2G and 3G sessions.

smf_service_stats

The fourg_only_ue label is marked as fourg_only_ue:unknown when the SessionID is greater than or equal to 64 for 2G and 3G sessions.

The GTPC metrics for 2G and 3G sessions are listed here:

Table 10. GTPC metrics

Metrics

Label Information

gtpc_app_events

Added version (v1 / v2) in the metrics.

The event_type is updated to reflect v1 messages.

gtpc_app_events_seconds

Added version (v1 / v2) in the metrics.

The event_type is updated to reflect v1 messages.

gtpc_app_priority_events

Added version (v1 / v2) in the metrics.

The event_type is updated to reflect v1 messages.

gtpc_app_total_unexpected_gtpc_msg_events

Added failed Message type and version.

gtpc_msg_total

Captures the v1 message names.

gtpc_app_validation_events

Captures the v1 specific message names, failure type, fail reason and rejection cause.

gtpc_msg_seconds

Captures the v1 message names.

gtpc_golang_enc_dec_stats

  • gtpc_msg_type is updated to reflect v1 messages.

  • gtpc_msg_status_cause is updated to display the v1 specific error.

gtpc_echo_msg_stats

Added version (v1 / v2) in the metrics

The GTPC metrics for node managers are listed here:

Table 11. GTPC metrics

Metrics

Description

nodemgr_gtpc_msg_stats

Added version (v1 / v2) in the metrics

nodemgr_gtpc_peer_status

Added version (v1 / v2) in the metrics

For more information on the metrics, refer UCC 5G SMF Metrics Reference 2025.02.0 Guide or above versions.