Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Überblick

Nachrichtenformat von ISDR-ISDA

Welche Rolle spielt EPS-Location-Information AVP?

Anrufablauf

Fehlerbehebung

Problemszenario

Lösung

Einleitung

In diesem Dokument wird die Fehlerbehebung für das fehlende EPS-Standortinformationen-AVP unter "Insert-Subscriber-Data-Answer" (Einfügen-Teilnehmerdaten-Antwort) beschrieben.

Voraussetzungen

Technische Daten 3GPP - 29.272

Anforderungen

Cisco empfiehlt, dass Sie mit dem StarOS Mobility Management Entity (MME)-Administrationsleitfaden vertraut sind.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Überblick

Insert-Subscriber-Data Request (ISDR) und Insert-Subscriber-Data Answer (ISDA) sind Nachrichten, die über die S6a/S6d-Schnittstelle in 3GPP-Netzwerken definiert werden. Mit diesen Meldungen kann der Home Subscriber Server (HSS) aktualisierte Teilnehmerdaten per Push an die MME (S6a) oder SGSN (S6d) senden, ohne dass eine Anforderung vom Zugangsnetz erforderlich ist.

Das Insert-Subscriber-Data-Verfahren wird verwendet, wenn der HSS im MME oder SGSN (Serving GPRS Support Node) gespeicherte Teilnehmerinformationen aktualisieren muss. Im Gegensatz zu anderen Diameter-Verfahren wird diese vom HSS initiiert, nicht vom MME/SGSN.

Typische Szenarien für die Nutzung von ISDR:

1. Administrative Updates: Ausgelöst durch Änderungen der in HSS gespeicherten Benutzerabonnementdaten (z. B. neue oder geänderte Abonnements).

2. Vom Bediener festgelegte Sperre: Wird verwendet, wenn Sperrregeln vom Operator angewendet, geändert oder entfernt werden.

3. Abonnentenverfolgung: Aktiviert oder aktualisiert die Abonnentenverfolgung in MME/SGSN.

4. UE-Erreichbarkeit: Teilt MME/SGSN mit, dass HSS benachrichtigt werden möchte, wenn die EU erreichbar ist.

5. T-ADS-Unterstützung (Terminating Access Domain Support): Fordert die für die Datenverkehrssteuerung auf Anwendungsebene (T-ADS) erforderlichen Daten an.

6. Standort-/Statusabruf: Ruft UE-Standort- oder Statusinformationen von MME/SGSN ab.

7. Informationen zur lokalen Zeitzone: Ruft die Zeitzonendetails des aktuellen UE-Standorts (Benutzergeräte) ab.

8. STN-SR-Update (Session Transfer Number for SRVCC): Aktualisiert die SRVCC-Weiterleitungsnummer (Single Radio Voice Call Continuity) aufgrund von Interaktionen mit SCC-AS (Service Centralization and Continuity Application Server).

9. PDN (Packet Data Network) GW (Gateway)-Informationen (nicht 3GPP): Aktualisiert MME/SGSN mit PDN-Gateway-Identitäten für Nicht-3GPP-Zugriff, einschließlich Notfalldiensten.

10. SMS-Abmeldung (Short Message Service): Benachrichtigt MME, dass die Registrierung für SMS-Dienste aufgehoben wurde.

11. P-CSCF (Proxy Call Session Control Function) Wiederherstellung: Auslösung der Wiederherstellung gemäß HSS-Anweisungen (gemäß 3GPP TS 23.380).

12. Überwachungsereigniskonfiguration: Fordert die Konfiguration/Meldung oder Löschung von Überwachungsereignissen an.

13. Aktive Zeitaktualisierung: Sendet die gewünschte PSM-Zeit (Energiesparmodus) an MME.

Nachrichtenformat von ISDR-ISDA

< Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777251 >

< Session-Id >

[ DRMP ]

[ Vendor-Specific-Application-Id ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Host }

{ Destination-Realm }

{ User-Name }

*[ Supported-Features]

{ Subscription-Data}

[ IDR- Flags ]

*[ Reset-ID ]

*[ AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

< Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 >

< Session-Id >

[ DRMP ]

[ Vendor-Specific-Application-Id ]

*[ Supported-Features ]

[ Result-Code ]

[ Experimental-Result ]

{ Auth-Session-State }

{ Origin-Host }

{ Origin-Realm }

[ IMS-Voice-Over-PS-Sessions-Supported ]

ETSI

3GPP TS 29.272 version 15.4.0 Release 15 70 ETSI TS 129 272 V15.4.0 (2018-07)

[ Last-UE-Activity-Time ]

[ RAT-Type ]

[ IDA-Flags ]

[ EPS-User-State ]

[ EPS-Location-Information ]

[Local-Time-Zone ]

[ Supported-Services ]

*[ Monitoring-Event-Report ]

*[ Monitoring-Event-Config-Status ]

*[ AVP ]

[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

Welche Rolle spielt EPS-Location-Information AVP?

Die EPS-Standortinformationen AVP unter dem Verfahren "Insert Subscriber Data" in 3GPP wird verwendet, um Informationen über den für EPS-Vorgänge (Evolved Packet System) relevanten Benutzerstandort bereitzustellen. Insbesondere ermöglicht sie dem HSS, MME für die aktuellen Standortdetails des Teilnehmers anzufordern. Dies kann die TAC- (Tracking Area Code) und eNB-ID (Evolved NodeB) der Zelle, die den Teilnehmer versorgt, umfassen. Der Hauptzweck dieses AVP besteht darin, dass der HSS Standortinformationen zu einem Teilnehmer abruft.

Anrufablauf

1. HSS initiiert ISDR:

Der HSS, der für das Speichern und Verwalten von Teilnehmerdaten zuständig ist, initiiert eine ISDR-Nachricht (mit dem EPS Location Info Request auf 1 unter den IDR-Flags AVP gesetzt) an die MME oder SGSN. Dies wird durch Ereignisse wie die Änderung eines Teilnehmerabonnement-Profils oder eine Standortaktualisierung ausgelöst.

2. MME/SGSN empfängt ISDR:

Das MME bzw. SGSN empfängt die ISDR-Nachricht und extrahiert die Teilnehmerdaten.

3. MME/SGSN führt Aktionen aus:

Das MME oder SGSN verwendet die empfangenen Teilnehmerstandortdaten, um seine lokale Datenbank zu aktualisieren und möglicherweise andere Prozeduren wie Standortaktualisierungen oder Serviceaktivierungen auszulösen.

4. MME/SGSN sendet ISDA:

Sobald der MME oder SGSN den ISDR verarbeitet und seine Daten aktualisiert hat, sendet er eine ISDA-Nachricht mit EPS-Standortinformationen AVP (unter denen die erforderlichen 3 AVPs - Zellen-ID, TAC, Age-of-Location-Info) an den HSS zurück, um den Abschluss des Prozesses zu bestätigen.

5. HSS erhält ISDA:

Der HSS empfängt die ISDA-Nachricht und verifiziert, dass die Daten erfolgreich in MME oder SGSN eingefügt wurden.

Fehlerbehebung

- Der primäre Aspekt ist, zu überprüfen, ob 'Update-Dictionary-Avps' in allen 'HSS-Diensten' vorhanden ist. In diesem Fall ist es 'NA'. Sie können dies überprüfen, indem Sie die folgende CLI ausführen:

******** show hss-peer-service service all *******

Service name                    : hss<>

Notify Request Message          : Enable

Service name                    : hss<>

Notify Request Message          : Enable

Update-Dictionary-Avps          : N/A

- Wenn diese Option aktiviert ist, können Sie diese Protokolle anfordern, um das Problem weiter zu beheben:

1. Request “show config verbose”

2. Monitor Subscriber with all the required options:

monitor subscriber <imsi>, along with 19,33,34,35,A,S,X,Y,+++

3. Debug logs:

logging filter active facility diameter level debug

logging filter active facility sessmgr level debug

logging filter active facility mme-app level debug

logging active

no logging active // to deactivate

4. Logging monitor:

configure

logging monitor msid <imsi>

exit

5. Request syslogs which captures the issue.

Problemszenario

In der gezeigten problematischen pcap (Paket 1) ist zu sehen, dass 'EPS location information AVP' in der Insert-Subscriber-Data Request (ISDR) angefordert/auf '1' gesetzt wird und in der Insert-Subscriber-data Answer (ISDA) (Paket 2) keine 'EPS information' vorhanden ist, obwohl sie angefordert wurde.

Um das Problem weiter zu beheben, müssen Sie sicherstellen, dass Sie alle angeforderten Protokolle durchlaufen.

Wie bereits erwähnt, müssen Sie zuerst die hss-peer-service-Konfiguration des problematischen Knotens überprüfen.

Referenzkonfiguration:

hss-peer-service <>

diameter hss-endpoint <>

no diameter update-dictionary-avps

--- more lines ---

exit

In dieser Konfiguration können Sie sehen, dass es "no ameter update-dictionary-avps" gab.

Daher wurde es gemäß dem StarOS Admin-Leitfaden auf die neueste Version aktualisiert, um das Problem zu beheben, nämlich Release 11.

Die Referenzkonfiguration lautet wie folgt:

Mode

Exec > Global Configuration > Context Configuration > HSS Peer Service Configuration

configure > context context_name > hss-peer-service service_name

Entering the above command sequence results in the following prompt:

[context_name]host_name(config-hss-peer-service)#

Syntax

diameter update-dictionary-avps { 3gpp-r10 | 3gpp-r11 | 3gpp-r9 }

no diameter update-dictionary-avps

no

Sets the command to the default value where Release 8 ('standard') dictionary is used for backward compatibility of previous releases.

3gpp-r10

Configures the MME /SGSN to signal additional AVPs to HSS in support of Release 10 of 3GPP 29.272.

3gpp-r11

Configures the MME /SGSN to signal additional AVPs to HSS in support of Release 11 of 3GPP 29.272.

Using this keyword is necessary to enable the MME to fully support inclusion of the Additional Mobile Station ISDN (A-MSISDN) flag of the Feature List AVP in Update Location Request (ULR) messages sent over the S6a interface to the HSS at the time a UE Attaches. For more information about supporting A-MSISDN, refer to the information for the a-msisdn command in the Call-Control Profile configuration mode.

3gpp-r9

Configures the MME/SGSN to signal Release 9 AVPs to HSS.

Usage Guidelines

Use this command to configure the 3GPP release that should be supported for this HSS peer service.

This command is only applicable for the 'standard' diameter dictionary as defined in the diameter hss-dictionary command.

Lösung

Nach der Implementierung der vorgeschlagenen CLI folgt die erfolgreiche Ablaufverfolgung, d. h. "EPS-Standortinformationen" in der ISDA.