5G 코어 네트워크에서 AMF 풀은 높은 가용성과 부하 분산을 위해 사용되는 경우가 많지만, 여러 AMF 인스턴스를 배치하는 것만으로는 충분하지 않습니다. gNB가 AMF 풀에 연결될 때는 어떤 AMF가 온라인 상태인지뿐 아니라 각 AMF가 제공하는 GUAMI, 지원하는 PLMN과 슬라이스, 상대 용량, 그리고 유지보수를 위해 특정 AMF가 서비스에서 제외될 때 트래픽을 어떻게 전환해야 하는지도 알아야 합니다.

N2 인터페이스는 이러한 정보 교환을 위한 제어 평면 경로를 제공합니다. SCTP 위에서 동작하며 NGAP 시그널링을 사용해 gNB와 AMF 간에 기능 정보를 교환하고 상태를 동기화합니다. 네트워크 초기 설정 시에는 먼저 SCTP 연결을 설정한 뒤 NG Setup 절차를 수행합니다. 운영 중 AMF 용량, GUAMI 정보 또는 SCTP 엔드포인트가 변경되면 구성 업데이트 절차를 통해 gNB에 알려야 합니다. 계획된 유지보수 전에는 AMF가 어떤 GUAMI가 사용 불가 상태가 될지 알리고 백업 AMF에 대한 정보를 제공할 수도 있습니다.

따라서 AMF 풀의 N2 인터페이스는 한 번 설정한 뒤 그대로 두는 연결이 아니라 지속적으로 유지되는 제어 관계로 보는 것이 적절합니다. 이런 관점에서 보면 설정, 업데이트, 재선택 절차를 하나의 완전한 관리 과정으로 이해하기가 훨씬 쉽습니다.

AMF 풀에서는 연결 설정만으로 왜 충분하지 않은가

기본적인 연결 관점에서 보면 gNB와 AMF 사이에 SCTP 연결이 설정되면 두 노드는 NGAP 메시지를 교환할 수 있습니다. 그러나 AMF 풀에서는 연결 가능하다는 사실만으로는 충분하지 않습니다.

하나의 서비스 영역에는 AMF1, AMF2, AMF3 등 여러 AMF 인스턴스가 존재할 수 있습니다. gNB는 해당 AMF에 도달할 수 있는지뿐 아니라 각 AMF가 지원하는 GUAMI, PLMN, 슬라이스와 현재 어느 정도의 상대 부하를 처리하기에 적합한지도 알아야 합니다. 이 정보가 없으면 모든 SCTP 연결이 UP 상태이더라도 gNB에는 새 UE에 적절한 AMF를 선택하는 데 필요한 정보가 부족할 수 있습니다.

N2 인터페이스 관리는 크게 세 단계로 나눌 수 있습니다.

이 세 절차는 AMF 관계의 수명 주기에서 서로 다른 세 단계를 다룹니다. 즉 초기 탐색, 기능 또는 구성 변경, 일시적 서비스 제외입니다. 이를 함께 보면 AMF 풀이 여러 코어 네트워크 노드 사이에서 부하 분산과 계획 유지보수를 어떻게 지원하는지 이해하기 쉬워집니다.

N2 설정 과정에서 SCTP와 NG Setup은 각각 무엇을 하는가?

엔지니어링 현장에서는 이 전체 단계를 흔히 단순히 ‘N2 설정’이라고 부릅니다. 하지만 프로토콜 수준에서는 먼저 SCTP 연결을 설정한 뒤 NGAP의 NG Setup 절차를 수행하는 두 개의 연속 단계로 구성됩니다.

gNB는 먼저 AMF 측 N2 인터페이스의 SCTP 엔드포인트 주소를 확보해야 합니다. 이 주소는 정적으로 구성하거나 적절한 주소 확인 메커니즘을 통해 얻을 수 있습니다. 그다음 gNB가 AMF와 SCTP 연결을 설정합니다.

일반적인 SCTP 연결 설정은 INIT, INIT ACK, COOKIE ECHO, COOKIE ACK의 네 번의 교환으로 구성됩니다. 이 교환이 완료되면 전송 계층에서 NGAP 시그널링을 운반할 준비가 됩니다. 그러나 gNB에는 아직 필요한 AMF 서비스 정보가 모두 없으므로 이어서 NG Setup 절차를 수행합니다.

gNB는 NG Setup Request를 전송합니다. 이 메시지에는 Global gNB ID, Supported TA List, RAN Node Name, Default Paging DRX 등의 정보가 포함될 수 있습니다. 실무적으로는 어떤 RAN 노드가 접속하는지, 어떤 추적 영역을 지원하는지, 기본 동작 파라미터가 무엇인지 AMF에 알려주는 메시지입니다.

요청을 받은 AMF는 NG Setup Response를 반환합니다. 응답에는 AMF Name, Served GUAMI List, 지원 PLMN 정보, RelativeAMFCapacity 등 AMF 측의 핵심 정보가 포함됩니다.

RelativeAMFCapacity는 AMF 풀에서 특히 중요합니다. 이는 단순히 AMF가 지원할 수 있는 최대 가입자 수를 의미하지 않습니다. 여러 AMF를 비교하고 이후 UE에 대한 AMF 선택과 부하 분산 결정을 내릴 때 gNB가 사용할 수 있는 상대 용량 기준입니다.

풀에 AMF1, AMF2, AMF3가 포함되어 있다면 gNB는 동일한 과정으로 관련 AMF와 N2 연결을 설정하고 각 노드가 반환하는 서비스 정보와 상대 용량 정보를 얻을 수 있습니다. 이를 통해 여러 AMF가 서로 독립된 제어 평면 노드가 아니라 하나의 조정된 풀로 동작할 수 있습니다.

패킷 캡처에서도 이 순서를 명확히 확인할 수 있습니다. 먼저 SCTP 핸드셰이크가 나타나고, 이어서 NG Setup Request와 NG Setup Response 메시지가 보입니다. 기본 N2 연결이 준비되면 UE 관련 등록 및 이동성 시그널링이 이 설정된 제어 평면 경로를 사용할 수 있습니다.

AMF 기능이 변경될 때 왜 gNB를 업데이트해야 하는가?

AMF 풀의 운영 상태는 고정되어 있지 않습니다. 클라우드 기반 5G 코어에서는 가입자 수요가 증가하면 AMF를 확장할 수 있으며 GUAMI 정보, 서비스 영역, 엔드포인트 주소 또는 처리 용량도 변경될 수 있습니다.

gNB가 초기 기동 시 획득한 파라미터를 계속 사용하면 RAN 측 AMF 선택 로직이 코어 네트워크의 실제 기능을 반영하지 못할 수 있습니다. 이때 AMF Configuration Update 절차가 중요해집니다.

이 절차는 특정 UE와 관련된 것이 아닙니다. AMF가 자체 구성 변경 사항을 NG-RAN에 알리기 위한 절차입니다. 예를 들어 AMF가 확장된 뒤 상대 처리 용량이 증가하면 새로운 RelativeAMFCapacity 값을 gNB에 통보할 수 있습니다. GUAMI 정보 변경과 SCTP 엔드포인트 주소 추가 또는 삭제도 같은 절차로 동기화할 수 있습니다.

예를 들어 오케스트레이션 또는 관리 시스템이 AMF1이 처리하는 사용자 수의 큰 증가를 감지하고 자동으로 처리 리소스를 확장했다고 가정해 보겠습니다. 확장 후 AMF1은 제어 평면 부하에서 더 큰 비중을 처리할 수 있으므로 용량 값도 그에 맞게 조정됩니다.

그다음 AMF1은 gNB에 AMF CONFIGURATION UPDATE를 보냅니다. 이 메시지에는 업데이트된 GUAMI 정보, 새로운 RelativeAMFCapacity 값, SCTP 엔드포인트 변경 사항이 포함될 수 있습니다. gNB는 업데이트를 적용한 후 AMF CONFIGURATION UPDATE ACKNOWLEDGE로 응답합니다.

이후 새 UE가 들어오거나 gNB가 새로운 AMF 선택을 수행해야 할 때는 네트워크 초기 기동 시 학습한 값이 아니라 업데이트된 정보를 사용할 수 있습니다.

이는 AMF 풀 운영의 중요한 원칙을 보여 줍니다. 부하 분산은 네트워크가 시작될 때 한 번만 계산되는 것이 아니라 코어 네트워크 리소스 변화에 따라 조정될 수 있습니다.

이 점은 클라우드 네이티브 5G 코어에서 특히 중요합니다. 컴퓨팅 리소스는 동적으로 확장·축소할 수 있지만 컴퓨팅 용량이 늘었다고 해서 RAN 측 AMF 선택 동작이 자동으로 바뀌는 것은 아닙니다. 업데이트된 제어 평면 파라미터도 gNB에 전달되어야 합니다. AMF Configuration Update는 코어 네트워크 리소스 변화와 RAN 측 선택 동작의 변화를 연결하는 시그널링 메커니즘입니다.

유지보수 전에 gNB는 AMF 재선택을 어떻게 준비하는가?

확장은 용량을 늘리는 과정입니다. 유지보수는 반대 상황을 만들 수 있습니다. 소프트웨어 업그레이드, 계획 유지보수 또는 기타 운영 작업 때문에 AMF를 일시적으로 사용할 수 없게 해야 할 수 있습니다.

AMF가 NG-RAN에 알리지 않고 단순히 오프라인 상태가 되면 장애가 발생할 때까지 gNB가 이전에 저장된 정보를 바탕으로 해당 AMF를 계속 선택할 수 있습니다. AMF 풀에서는 특정 AMF 식별자가 곧 사용 불가 상태가 된다는 사실을 미리 gNB에 알리는 것이 더 적절합니다.

NGAP의 AMF Status Indication 절차는 이러한 AMF 관리 시나리오에 사용됩니다.

AMF1이 소프트웨어 업그레이드를 받아야 한다고 가정하겠습니다. 유지보수가 시작되기 전에 AMF1은 gNB에 AMF STATUS INDICATION을 보내고 곧 사용할 수 없게 될 GUAMI를 식별할 수 있습니다. 메시지에 AMF2와 같은 Backup AMF Name도 포함되고 관련 기능이 지원되는 경우, gNB는 이후 재선택에서 해당 AMF를 고려할 수 있습니다.

gNB가 상태 지시를 받으면 표시된 GUAMI를 사용 불가로 처리하고 이후 AMF 선택과 재선택을 그에 맞게 조정합니다.

이것이 기존의 모든 UE 컨텍스트가 정확히 같은 시점에 AMF1에서 AMF2로 기계적으로 이동된다는 의미는 아닙니다. 목적은 이후 AMF 선택 또는 재선택이 필요할 때 서비스에서 빠지고 있는 AMF를 NG-RAN이 계속 선택하지 않도록 하는 것입니다.

예를 들어 나중에 UE가 이동성 등록 업데이트를 시작하면 gNB는 관련 시그널링을 다른 AMF로 라우팅할 수 있습니다. 새로운 AMF는 이동성 관리 기능을 계속 제공하고 절차상 필요한 경우 UE에 새로운 5G-GUTI를 할당할 수 있습니다.

운영 관점에서 AMF Status Indication은 본질적으로 계획된 서비스 제외를 위한 메커니즘입니다. ‘AMF1이 유지보수에 들어간다’와 같은 운영 이벤트를 AMF가 실제로 사용 불가 상태가 되기 전에 NG-RAN이 이해하고 활용할 수 있는 프로토콜 수준의 상태 정보로 바꿔 줍니다.

AMF 풀은 이 세 절차를 통해 실제로 무엇을 관리하는가?

NG Setup, AMF Configuration Update, AMF Status Indication을 각각 따로 보면 서로 관련 없는 세 개의 NGAP 절차처럼 보이기 쉽습니다. 그러나 AMF 풀의 전체 수명 주기 관점에서 보면 이들의 관계가 훨씬 분명해집니다.

NG Setup은 초기 관계를 설정합니다. gNB가 처음 AMF에 연결할 때는 어떤 AMF와 통신 중인지, 그 AMF가 어떤 서비스를 제공하는지, 풀 내에서 상대 처리 능력이 어느 정도인지 알아야 합니다.

AMF Configuration Update는 기능 및 구성 변경을 처리합니다. AMF는 계속 사용 가능하지만 GUAMI 정보, 상대 용량 또는 전송 엔드포인트가 변경되었으므로 NG-RAN은 저장된 정보를 갱신해야 합니다.

AMF Status Indication은 가용성 변경을 처리합니다. AMF가 유지보수 또는 일시적 서비스 제외를 준비할 때 gNB는 관련 GUAMI를 사용 불가로 처리하고 이후 AMF 재선택을 준비해야 합니다.

이 절차들은 gNB가 하나의 중요한 운영 관점을 유지하도록 합니다. 즉 어떤 AMF가 사용 가능한지, 어떤 서비스를 제공하는지, 어느 정도의 상대 부하를 처리하기에 적합한지, 그리고 어떤 AMF가 서비스에서 제외되는 과정에 있는지를 파악하게 합니다.

따라서 AMF 풀은 여러 AMF 인스턴스를 배치하는 것만으로 고가용성을 달성하지 못합니다. gNB는 AMF 기능과 상태에 대한 최신 정보를 지속적으로 유지하고 선택 결정을 내릴 때 이를 사용해야 합니다. 그래야 다중 AMF 배치가 부하 분산, 탄력적 확장·축소, 계획 유지보수를 효과적으로 지원할 수 있습니다.

같은 논리는 장애 분석에도 유용합니다. 먼저 SCTP 연결이 정상인지 확인한 다음 NG Setup이 성공적으로 완료되었는지 확인합니다. 연결은 유지되는데 부하 분산이 비정상이라면 AMF Configuration Update 시그널링과 RelativeAMFCapacity를 점검합니다. 서비스에서 제외되는 AMF로 트래픽이 계속 전달된다면 AMF Status Indication, GUAMI 가용성 정보, AMF 재선택 동작을 확인합니다.

자주 묻는 질문

패킷 캡처에서 SCTP 장애와 NGAP 장애를 빠르게 구분하려면 어떻게 해야 하는가?

먼저 SCTP 연결이 정상적으로 설정되었는지 확인합니다. INIT, INIT ACK, COOKIE ECHO, COOKIE ACK 교환이 완료되지 않았다면 문제는 아직 전송 계층에 있습니다. SCTP는 설정되었지만 NG Setup Response가 수신되지 않거나 NGAP 수준 오류가 반환되었다면 NGAP 파라미터, TA 구성, PLMN 정보, AMF 측 설정을 계속 점검해야 합니다.

RelativeAMFCapacity는 AMF가 지원할 수 있는 최대 UE 수를 의미하는가?

아닙니다. RelativeAMFCapacity는 AMF 풀 내부에서 사용하는 상대 용량 지표로 이해하는 것이 적절합니다. NG-RAN이 선택 과정에서 서로 다른 AMF의 상대 처리 능력을 비교하도록 돕는 값이며 절대적인 가입자 수 한도로 직접 해석해서는 안 됩니다.

GUAMI 정보가 변경될 때 AMF 로컬 구성만 변경해서는 왜 충분하지 않은가?

gNB는 이미 N2 인터페이스를 통해 얻은 AMF 서비스 정보를 저장하고 있습니다. AMF가 NG-RAN에 알리지 않고 GUAMI 구성을 변경하면 AMF 식별자와 서비스 가용성에 대한 양측의 인식이 서로 달라질 수 있습니다. 따라서 업데이트된 정보는 해당 NGAP 관리 절차를 통해 동기화해야 합니다.

AMF Status Indication에는 항상 Backup AMF Name이 포함되어야 하는가?

아닙니다. Backup AMF Name은 선택 사항입니다. 포함되지 않더라도 NG-RAN은 사용 불가로 식별된 GUAMI를 처리하고 적절한 AMF 관리 및 재선택 동작을 수행해야 합니다. Backup AMF Name이 포함되고 NG-RAN이 해당 절차를 지원한다면 재선택 시 지정된 백업 AMF를 고려할 수 있습니다.