Troubleshooting

Using CLI Data

This section describes the show and clear commands that are used for troubleshooting.

show subscriber

This section describes the show subscriber commands for the existing subscribers sessions.

Table 1. show subscriber Command Output Description

Field

Description

|

Output modifiers.

all

Displays all the existing subscriber sessions.

supi

Displays subscriber sessions based on SUPI ID.

gnodeb-id

Displays the gnodeb-id of the session.

clear subscriber

This section describes the clear subscriber commands for the existing subscribers sessions.

Table 2. clear subscriber Command Output Description

Field

Description

|

Output modifiers.

all

Clears all the subscriber sessions.

gnodeb-id

Clears the sessions that have the specified gnodeb-id.

mcc

Clears the subscriber that has the specified MCC associated to the gnodeb-id.

mnc

Clears the subscriber that has the specified MNC associated to the gnodeb-id.

gr-instance

Clears one or more subscribers from the provided GR Instance

imei

Clears the sessions based on the IMEI value

nf-service

Clears subscriber based on configured network function service such as SMF and SGW.

supi

Clears the sessions based on the SUPI value.

Logs

Feature Description

AMF utilizes the common logging framework to generate logs from its microservices.

The supported log levels are:

  • Error

  • Warn

  • Info

  • Debug

  • Trace


Note


Warn level logging takes place during production.


Error

These errors are fatal errors, which can impact service for multiple subscribers.

Examples of the error messages:

  • Node discovery of SBA fails after query from NRF and local configuration

  • Mandatory IE missing in an NGAP message

  • Memory cache startup errors

  • Endpoint not found

Sample log:

[ERROR] [ApplicationContext.go:1820] [infra.dpd.core] Ping Unsuccessful for client Id 4 Name: amf-protocol-ep0 Setname: amf-protocol-ep Host: amf-protocol-ep Port: 9003 Url:  for [246]

Warn

These errors impact few specific call-flows majorly, but not blockers of functionality.

Example of the warning messages:

  • Node discovery of SBA fails but we have more options to retry.

  • Mandatory IE missing in a NAS message

  • RPC timeout

  • Procedural timeout

  • Validation failure (not critical)

    Example: Registration rejected as Registration request message received registration type as the Reserved registration type.

  • External entity sending unexpected or negative response

    Example: Handover Cancel, Hand over Failure, or Initial Context Setup Failure

  • Unexpected value of objects maintained by AMF

    Example: NIL value of transaction

  • Unable to fetch a subscriber

Sample log:

[WARN] [amf-service.amf-app.messageprocessor] No procedure defined for message type 763

Info

This log level purpose is to know information for cause.

Examples of the information messages:

  • Procedural outcome Example: Disabling of ICSR for Registration

  • Collision abort, cleanup, suspend, or continue.

Sample log:

[INFO] [amf-service.amf-app.auth] Sending N12 Authentication Request to Rest EP

Debug

This log level purpose is to get debug messages.

Example of the debug messages:

  • All external exchanged messages

  • Sending Registration accept to UE

  • State machine changes

  • Collision detailed logging

Sample log:

[DEBUG] [process.go:1606] [amf-service.amf-app.reg] [supi:123456789012345] [supi:123456789012345] [1] Preparing registration accept to UE 123456789012345

Trace

This log level purpose is to get content of all external tracing messages.

Example of the trace messages:

  • Registration request message

  • N1N2 transfer message

Sample log:

[TRACE] [process.go:1627] [amf-service.amf-app.reg] [supi:123456789012345] [supi:123456789012345] 
[496] Sending RegistrationAccept:&MsgNas {N1MsgType:154,N2MsgType:0,N1Msg:&MsgNas_MsgRegistrationAccept
{MsgRegistrationAccept:&ngn_nas.PBRegistrationAccept{ExtendedProtocolDiscriminator:126,SecurityHeaderType:
&SecurityHeaderType{HeaderType:PLAIN_5G_NAS,},MessageIdentity:&MessageType{MessageType:REGISTRATION_ACCEPT,}
,VgsRegistrationResult:&VgsRegistrationResult{EmergencyRegistered:false,NssaaPerformed:false,SmsAllowed:false,
VgsRegistrationResultValue:TGPP_ACCESS,}

How it Works

This section describes how this feature works.

Log Tags

Use log tags to tag the logs for specific procedures which are part of a flow or an event. Enabling of AMF logging takes place at different log levels for different log tags.

Name

Purpose

Example Log tags

AMF service

To capture procedures.

  • LogTagReg

  • LogTagPDU, and so on

Protocol Endpoint

To capture on the interface.

  • LogTagNas

  • LogTagNgap

  • LogTagNonUE

Rest Endpoint

To capture on the interface.

  • LogTagN11

  • LogTagN14

  • LogTagNRF

  • LogTagN11OrN14 (N1NMsgTransfer can come from N14/N11 interfaces) and so on

Frequently Encountered Scenarious

Geo-Replication Pod in Pending State

This section describes how to correct geo-replication pod conflict if shared hardware setup.

Problem

After completing Day1 configuration on AMF, when you deploy AMF and SMF on the same mode, the geo-replication pod is in pending state.

The following table lists the ports configured use by a geo-replication pod. The port numbers are for reference purpose only.


Note


The default base port is 15000. You can change the default base port.


Table 3. Ports Configured for Geo-replication Pod

15000

INFRA_PROMETHEUS_PORT

15001

PPROF_EP_PORT

15002

INFRA_ADMIN_PORT

15003

IPC_EP_PORT

15004

GEO_KEEPALIVED_PORT

15005

INFRA_DIAG_PORT

Resolution

  1. Change the default base port for geo-pod from 15000 to other available port range.

    instance instance-id <instance_id> endpoint geo internal base-port start <new_port>


    Note


    <instance_id> should match the <local_instance_id> .

    Configure the relevant keepalive port in the SMI configuration (base_port + 4) .

    This configuration is required only for the GR setup.


  2. To verify that the new port change configuration is reflecting, run the following command.

    kubectl describe pod georeplication-pod-0 -n cn | grep -i port
  3. SSH to the server where geo-pod is running and run the following command.

    sudo netstat -plan | grep grpod | grep <port_range> | grep -v