AMF의 MT-LR 통화 흐름 및 서드파티 LMF, GMLC와의 공통 통합 문제 해결

다운로드 옵션

PDF (282.2 KB)
다양한 디바이스에서 Adobe Reader로 보기

업데이트:2026년 5월 4일

문서 ID:225816

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 AMF MT-LR(Mobile-Terminated Location Request) 기능, 통합 및 네트워크 엔지니어 문제 해결에 대해 설명합니다.

사전 요구 사항

요구 사항

Cisco에서는 AMF(Access and Mobility Management Function)의 기능에 대해 알고 있는 것이 좋습니다

사용되는 구성 요소

이 문서의 정보는 5G 코어 네트워크 내 AMF인 Cisco AMF와 관련되어 있다.

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

배경 정보

위치 서비스는 사용자 환경뿐만 아니라 긴급 통화 및 합법적 가로채기와 같은 중요한 규제 요구 사항에도 필수적인 최신 모바일 네트워크입니다. 5G 코어에서 AMF는 이러한 위치 요청을 처리하는 데 중추적인 역할을 한다.

MT-LR(Mobile-Terminated Location Request)이란 무엇입니까?

AMF는 NI-LR(Network Induced Location Request) 및 MT-LR을 비롯한 다양한 유형의 위치 요청을 지원합니다.

MT-LR은 외부 엔티티, 일반적으로 GMLC(Gateway Mobile Location Center)가 UE(User Equipment)의 위치를 요청할 때 시작됩니다. GMLC는 이 요청을 AMF에 전달하고, AMF는 사용자 장비의 정확한 위치를 결정하기 위해 위치 관리 기능(LMF)과 조정한다. 식별되면, 위치 정보는 GMLC로 다시 전송된다.

AMF는 MT-LR에 대해 '현재 위치' 또는 '현재 또는 마지막으로 알려진 위치'를 제공할 수 있으며, 사용자 장비의 긴급성 및 활동 상태에 따라 유연성을 제공합니다.

MT-LR의 주요 통합 접점

MT-LR 프로세스의 경우 AMF는 주로 다음과 통신합니다.

GMLC: 위치 요청을 시작합니다.
LMF: 사용자 장비 위치를 결정합니다.
gNB: 사용자 장비 포지셔닝과 관련된 5G 기지국.

MT-LR 통화 흐름 및 통합 문제

MT-LR 프로세스에는 AMF, GMLC 및 LMF 간의 3가지 주요 교환이 포함됩니다.

GMLC-AMF(Positioning Information Request Exchange)
위치 요청 결정(AMF에서 LMF로)
사용자 장비 포지셔닝(AMF를 통해 gNB/UE에 LMF 제공 및 반환)

이 세 단계에 대한 설명과 공통적인 통합 과제에 대해 여기서 설명한다.

1. 포지셔닝 정보 요청 GMLC - AMF

MT-LR 프로세스는 GMLC가 ProvidePosInfoRequest를 AMF에 전송할 때 시작됩니다. 이 요청은 전체 위치 결정 시퀀스를 시작하므로 매우 중요합니다. 그런 다음 AMF는 사용자 장비의 위치를 검색하기 위해 LMF와 같은 다른 네트워크 기능과 조정한다.

문제 해결 중점 사항: ProvidePosInfoRequest의 UE 식별자

ProvidePosInfoRequest에서 사용되는 UE 식별자(구체적으로는, Namf_Location ProvidePositioningInfo)와 일반적인 통합 문제가 발생한다.

사양 요구 사항: 역사적으로 3GPP 사양(TS 23.271, TS 23.273)은 5G 시스템에서 위치 요청을 위한 주요 식별자로 SUPI(IMSI)를 사용하도록 의무화했습니다. 리소스 URI {apiRoot}/namf-loc/<apiVersion>/{ueContextId}의 ueContextId는 imsi-XXXX 또는 imei-XXXX와 같은 패턴과 유사해야 합니다.
일반적인 문제: GMLC는 ueContextId 또는 요청 본문 내에서 SUPI(IMSI) 또는 PEI(IMEI) 대신 일반 MSISDN을 잘못 보낼 수 있습니다. 이러한 경우 AMF는 메시지를 올바르게 디코딩하고 검증하지 못합니다.
해결/진화: 3GPP 사양(29.518)의 릴리스 18.6.0에서 AMF 서비스가 위치 요청의 일부로서 MSISDN을 포함하는 GPSI(Generic Public Subscription Identifier)를 수락하도록 업데이트되었습니다. 이는 MSISDN을 사용하여 인바운드 로머를 찾는 데 특히 중요합니다.

2. 위치 요청 결정: AMF - LMF

성공적인 ProvidePosInfoRequest를 게시하면 AMF는 Namf_Location DetermineLocationRequest를 LMF에 보냅니다. 이 요청은 LMF가 사용자 장비의 위치를 결정하는 데 도움이 되도록 AMFID, 상관관계 ID, NCGI, PEI, SUPI, 및 ueConnectivityStates와 같은 필수 정보를 포함한다.

3. 사용자 포지셔닝 AMF를 통해 gNB/UE에 LMF

LMF는 DetermineLocationRequest를 처리한 후, UE 포지셔닝 절차를 개시한다. LMF는 AMF에 N1/N2 메시지를 전송하는데, 이는 gNB에 전달자 역할을 하거나(N2) UE에 직접(N1) 한다. 그런 다음 AMF는 gNB/UE로부터 위치 정보를 다시 수신하고 이를 LMF와 공유한다.

이 전달 메커니즘은 매우 중요합니다.

NRPPa-PDU: 포지셔닝 명령 또는 측정 요청을 포함하는 코어 페이로드는 NRPPa-PDU(New Radio Positioning Protocol A)입니다.
캡슐화: NRPPa-PDU는 N2 컨테이너 내에서 캡슐화됩니다.
AMF의 역할: AMF는 LMF로부터 이 N2 컨테이너를 수신하고 gNB에 전송할 다운링크 UEAassociatedNRPPaTransport 메시지를 구축합니다(NGAP 사양 38.413에 자세히 설명).
API 컨텍스트: 통신에서는 Namf_Communication N1N2 Message Transfer (UE Specific) 서비스 작업(예: /ue-contexts/{ueContextId}/n1-n2-messages)을 사용합니다. 요청 본문은 N1N2MessageTransferReqData입니다.

문제 해결 중점 사항: N1/N2 컨테이너 전송 형식

여기서 중요한 통합 문제는 N1/N2 컨테이너를 전송하기 위한 메시지 형식과 관련이 있습니다.

예상 형식: 사양에 따라 N1N2MessageTransferReqData(NRPPa-PDU가 있는 N2 컨테이너 포함)는 멀티파트/관련 메시지로 이상적으로 전송되어야 합니다. 이 형식은 JSON 데이터 및 이진 부분(예: N2 컨테이너)을 모두 허용합니다.
일반적인 문제: N2 컨테이너가 있음에도 불구하고 AMF 로그에 다음과 같은 오류가 표시되어야 합니다.

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf] Not Received the Mandatory IE: N1/N2 컨테이너를 모두 받지 못했습니다."

이는 LMF가 요청 본문을 multipart/related로 전송하지 않고 잘못된 형식(예: 라인 기반 텍스트 데이터)을 사용하기 때문에 종종 발생합니다. AMF는 메시지를 올바르게 디코딩하고 검증하지 못합니다.

해결 방법: LMF에서 3GPP 사양을 준수하여 N1N2MessageTransferReqData를 멀티파트/관련 HTTP 메시지로 올바르게 포맷해야 합니다.

문제 해결 중점 사항: LCS 상관 관계 ID

LCS 상관 관계 ID는 서로 다른 네트워크 기능(AMF, LMF, gNB)에서 단일 LCS(Location Services) 세션(예: MT-LR)과 관련된 모든 메시지 및 절차를 연결하고 추적하는 데 사용되는 고유 식별자입니다. 포지셔닝 요청에 적합한 컨텍스트를 보장합니다.

사양: LCS Correlation ID는 ueContextId에 대한 LCS 관련 UE 특정 N1 및/또는 N2 메시지를 전달할 때 적용됩니다. URI(/ue-contexts/{ueContextId}/n1-n2-messages의 cid) 및 본문 내의 JSON IE(lcsCorrelationId)로 정의됩니다.
일반적인 문제: LMF에서 잘못된 LCS 상관 관계 ID를 보내면 AMF에서 이를 처리하지 못해 다음과 같은 오류가 발생합니다.

"[ERROR] [amf-service.amf-app.n1n2] 잘못된 LCS 상관 관계 ID".

해결 방법: AMF에서 초기 LCS 상관 관계 ID를 전송하고 LMF에서 세션 ID를 이 값으로 설정해야 합니다. 그런 다음 이 동일한 상관관계 ID를 모든 인터페이스(AMF-LMF, AMF-gNB)에서 라우팅 식별자로 일관성 있게 사용해야 합니다. LMF가 AMF에서 제공하는 LCS 상관 관계 ID를 올바르게 수신하고 재사용하고 있는지 확인합니다.

결론

5G AMF의 MT-LR 기능은 위치 서비스에 매우 중요합니다. 기본 통화 흐름이 표준화되지만, 성공적인 통합 및 운영은 특히 UE 식별자, N1/N2 컨테이너에 대한 메시지 형식, LCS 상관 관계 ID의 일관된 사용과 관련하여 3GPP 사양을 엄격하게 준수하는 것에 크게 의존합니다.

개정 이력

개정	게시 날짜	의견
1.0	04-May-2026	최초 릴리스

기고자

소우미야 드위베디
컨설팅 엔지니어링 기술 리더