This document describes how to troubleshoot the problem that occurs when 4G Attach Success Rate (ASR) Key Performance Indicator (KPI) degradation takes place when mme-hss-user-unknown disconnect reason is increased.
Cisco recommends that you have knowledge of these topics:
Hardware knowledge of 5000/5500
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Attach Success Rate
Key Performance Indicator
Authentication Information Request
Authentication Information Answer
Capability Exchange Request
Capability Exchange Answer
Mobility Management Entity
Home Subscriber Server
Data Processing Card
Request for Comments
The Service provider reported the 4G ASR degradation in one MME and the disconnect reason 'mme-hss-user-unknown' was increased.
"mme-hss-user-unknown(375)" disconnect reason describes the total number of sessions disconnected because the MME HSS user is unknown.
One failure trace that was captured reported that HSS was rejecting the Authentication as result-code DIAMETER_MISSING_AVP (5005) in AIA message.
MME constantly got "DIAMETER_MISSING_AVP (5005)" from HSS and this is how the failure AIA message looks like:
It seems that the "Supported Vendor IDs" AVP is not negotiated with DPC Card 2 and so the failure is observed for that card only.
As per the RFC 3588, Supported-Vendor-Id AVP - This is used in the CER and CEA messages in order to inform the peer that the sender supports (a subset of) the vendor-specific AVPs defined by the vendor identified in this AVP. Vendor-Id AVP - In combination with the Supported-Vendor-Id AVP, this might be used in order to know which vendor-specific attributes might be sent to the peer.
In order to exchange the capabilities between diameter peer and client, this action plan is suggested to the service provider.
The action plan is to migrate DPC Card 2 with standby DPC Card 10.
[local]SGSN-MME-03# card migrate from 2 to 10 Are you sure? [Yes|No]: yes
The service provider performed DPC Card 2 migration with standby DPC card 10.
Post activity, the supported vendor IDs(10415) appeared to be ok for card 10 with the respective hss-peer and the ASR KPI seemed to be ok too.
[local]SGSN-MME-03# show diameter peers full peer-host dra01.epc.mnc0XY.mcc404.3gppnetwork.org