알림 요청에서 누락된 방문 네트워크 식별자 AVP 트러블슈팅

소개

이 문서에서는 S6a 인터페이스를 통해 MME와 HSS 간의 'Notify request(요청 알림)' 메시지에서 누락된 VNI 문제를 해결하는 방법을 설명합니다.

사전 요구 사항

3GPP 기술규격 - 29.272, 29.229

 설명 요청(RFC) - 6733

요구 사항

Cisco에서는 StarOS-MME(Mobility Management Entity) 관리 가이드에 대해 알고 있는 것이 좋습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

개요

NOR/NOA(Notification Request and Answer)는 S6a/S6d 인터페이스를 통한 가장 간단한 메시지 중 하나입니다. 이 메시지의 기본 아이디어는 홈 가입자 서버 (HSS)에 네트워크 및 사용자 장비 정보의 변경에 대한 정보를 알리는 것입니다.

통지 절차는 HSS에 다음 사항을 통지하기 위해 MME와 HSS 사이, 또한 SGSN(Serving GPRS Support Node)과 HSS 사이에서 사용된다.

• APN(Access Point Name)에 대한 PDN(Packet Data Network) Gateway(GW)의 할당/변경/제거
• MME 간 위치 업데이트가 발생하지 않지만 HSS가 현재 SGSN에 Cancel Location을 전송할 필요성에 대해 통지해야 하는 경우.
• 사용자 엔티티(UE)는 하나 이상의 짧은 메시지를 수신할 수 있는 메모리 용량을 갖는다
• UE에 다시 연결할 수 있게 되었습니다.

NOR-NOA의 메시지 형식

< Notify-Request> ::= < Diameter Header: 323, REQ, PXY, 16777251 >
                      < Session-Id >
                      [ Vendor-Specific-Application-Id ]
                      { Auth-Session-State }
                      { Origin-Host }
                      { Origin-Realm }
                       [ Destination-Host ]
                                                 { Destination-Realm }

                      { User-Name }
                    * [ Supported-Features ]
                      [ Terminal-Information ]
                      [ MIP6-Agent-Info ]
                      [ Visited-Network-Identifier ]
                      [ Context-Identifier ]
                      [Service-Selection]
                      [ Alert-Reason ]
                      [ UE-SRVCC-Capability ]
                      [ NOR-Flags ]
                   [Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ]
                    *[ AVP ]


< Notify-Answer> ::= < Diameter Header: 323, PXY, 16777251 >
                     < Session-Id >
                     [ Vendor-Specific-Application-Id ]
                     [ Result-Code ]
                     [ Experimental-Result ]
                     { Auth-Session-State }
                     { Origin-Host }
                     { Origin-Realm }
                     [ OC-Supported-Features ]
                     [ OC-OLR ]
                    *[ Supported-Features ]
                    *[ AVP ]
                    *[ Failed-AVP ]

Process

1. 시작: 프로세스는 통상적으로 UE와 관련된 관련 이벤트가 발생할 때 MME에 의해 개시된다.
2. NOR 메시지 상기 MME는 상기 HSS에게 NOR 메시지를 송신한다. 이 메시지에는 IMSI(International Mobile Subscriber Identity)와 같은 필수 식별자 및 이벤트 또는 변경 세부사항이 포함됩니다.
3. HSS에서 처리: HSS는 요청을 처리하고, 기록을 업데이트하며, 수신된 정보에 기초하여 필요에 따라 추가 조치를 수행할 수 있다.
4. 알림 응답: HSS는 업데이트를 확인하고 필요한 추가 데이터 또는 지침을 포함하여 다시 MME에 Notify Response를 보냅니다.

방문 네트워크 식별자 AVP의 역할은 무엇입니까?

VNI(Visited-Network-Identifier) AVP(Attribute Value Pair)는 Octet-String 형식입니다. 이 AVP에는 홈 네트워크가 방문한 네트워크(예: 방문한 네트워크 도메인 이름)를 식별하는 데 도움이 되는 식별자가 포함되어 있습니다.

VNI AVP는 사용자가 현재 있는 네트워크, 즉 '방문'을 식별하는 역할을 하며 주로 로밍 시나리오에서 사용됩니다. 이 정보는 다음과 같은 경우에 매우 중요합니다.

• 라우팅 결정: 요청 및 응답이 홈 네트워크와 방문 네트워크 간에 올바르게 라우팅되는지 확인합니다.
• 정책 시행: 사용자의 위치 및 홈 네트워크와의 방문 네트워크의 계약에 따라 적절한 네트워크 정책 및 과금 규칙을 적용합니다.

Visited-Network-Identifier AVP에 대한 3gpp 참조

통화 흐름

NOR 통화 흐름

Notify-Request/Answer 통화 흐름

1. MME의 이벤트 트리거

• HSS에게 알릴 필요가 있는 가입자 이벤트가 MME에서 발생한다. 예를 들면 다음과 같습니다.
• 위치 업데이트
• 방문한 네트워크의 변경(예: 로밍)
• 서브스크립션 상태 업데이트(예: 활성 또는 비활성)
• MME는 NOR 메시지를 준비합니다.

2. MME가 Notify-Request 전송

• MME는 다음과 같은 주요 AVP로 NOR 메시지를 구성한다.
  • 가입자가 현재 있는 방문 네트워크의 PLMN(Public Land Mobile Network) ID 도메인 이름을 포함합니다.
• 세션 ID: 지름 세션의 고유 식별자입니다.
• Origin-Host 및 Origin-Realm: MME를 발신자로 식별합니다.
• Destination-Host 및 Destination-Realm: HSS를 수신자로 식별합니다.
• IMSI(사용자 식별자): 가입자의 고유 식별자입니다.
• VNI
• 인증 세션 상태: 세션이 상태 저장 또는 상태 비저장 상태인지 나타냅니다.

3. HSS가 Notify-Request 수신 및 처리

• HSS는 NOR를 처리하고 AVP를 검증합니다.
• IMSI를 선택하여 가입자의 레코드를 찾습니다.
• VNI가 알려지고 지원되는 네트워크에 해당하는지 확인하기 위해 VNI를 검증합니다.
• 가입자의 데이터를 업데이트하여 새 방문 네트워크 또는 상태를 반영합니다.
• 검증이 성공하면 HSS는 성공적인 응답을 준비합니다.
• 문제가 있는 경우(예를 들어, 누락 VNI), HSS는 오류 응답을 준비한다.

4. HSS에서 NOA(Notify-Answer) 전송

• HSS는 MME에 NOA 메시지를 보낸다.
  • DIAMETER_SUCCESS(2001): 성공적인 처리를 나타냅니다.
  • DIAMETER_INVALID_AVP_VALUE(5004): VNI가 유효하지 않은 경우
  • DIAMETER_MISSING_AVP(5005): VNI가 누락되었지만 필요한 경우
  • 오류가 발생한 경우 VNI AVP를 포함합니다.
• 결과 코드
• 실패한 AVP(해당되는 경우)

5. MME가 Notify-Answer 처리

• NOA 수신 시:
• Result-Code가 성공하면 MME는 작업을 계속한다
• 오류가 표시되면 MME는 문제를 식별하기 위해 Failed AVP(있는 경우)를 분석합니다

문제 해결

• 주요 측면은 모든 'HSS 서비스'에서 'notify request'가 'enabled'인지 확인하는 것입니다. 다음 CLI를 실행하여 동일한 작업을 수행할 수 있습니다.
  
  

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

Service name                    : hss<>
Notify Request Message          : Enable
Service name                    : hss<>
Notify Request Message          : Enable

• 이 확인란을 선택하면 문제를 더 자세히 트러블슈팅하기 위해 다음 로그를 요청할 수 있습니다.
  
  

1. Request “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.

문제 시나리오

문제가 있는 pcap

이 참조 PCAP(Packet Capture)에서 'notify-answer' 아래에 누락된 'visited-network-Identifier'를 볼 수 있습니다.

패킷 190은 'Notify request'이고, 191은 'Notify Answer'이다.

이 시나리오의 직경 결과 코드는 'Diameter_Missing_AVP'입니다. 게시물에는 'Visited-Network-Identifier'를 가리키는 'Failed AVP'도 표시됩니다. 그러면 'data empty'가 표시됩니다.

참고: Failed AVP는 특정 AVP의 오류로 인해 요청이 거부되거나 완전히 처리되지 않을 때 디버깅 정보를 제공하는 그룹화된 AVP입니다.

Failed-AVP의 몇 가지 이유는 다음과 같습니다.

· 올바르게 구성되지 않은 AVP

· 인식되지 않거나 지원되지 않는 AVP

· 잘못된 AVP 값

· 누락된 필수 AVP

· 명시적으로 제외된 AVP

· AVP는 0, 1 또는 0-1로 제한되지만, 두 번 이상 발생

문제를 더 자세히 해결하려면 요청된 모든 로그를 진행해야 합니다.

앞에서 주장한 대로 먼저 문제가 되는 노드의 hss-peer-service 컨피그레이션을 확인해야 합니다.

참조 구성:

hss-peer-service <>
      diameter hss-endpoint <>
      no diameter update-dictionary-avps
      --- more lines ---
    exit

이 구성에서는 'no diameter update-dictionary-avps'가 있음을 확인할 수 있습니다. 3gpp-release에 매핑된 update-dictionary가 없을 때 문제가 분명했다. 또한 CLI 'diameter update-dictionary-avps 3gpp-r9/10'이 존재하고 여전히 문제가 분명한 몇 가지 시나리오가 발생할 수 있습니다.

따라서 이 문제를 해결하기 위해 StarOS 관리 가이드에 따라 최신 릴리스로 업데이트되었으며, 이는 릴리스 11입니다.

참조 구성은 다음과 같습니다.

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.