[6G SBA #3] 복잡한 5G SBA를 어떻게 단순하고 확장 가능하게 할 것인가?

SBA 구조를 어떻게 더 단순하고 확장 가능하게 만들 것인가

---

5G Service-Based Architecture(SBA)는 클라우드 네이티브 환경을 지향하며 유연성과 확장성을 제공하도록 설계되었지만,

실제 구현에서는 오히려 구조적 복잡성이 증가하는 문제가 나타나고 있다.

 

우선, resilience와 redundancy를 위한 다양한 메커니즘이 혼재하면서 전체 구조의 일관성이 저하되고 있다.

NF set, NF service set, Backup AMF와 같은 서로 다른 방식이 동시에 존재하면서 기능 중복과 충돌 가능성이 발생하고,

vendor별 지원 차이로 인해 interoperability 문제 또한 심화된다.

 

또한, NRF 중심의 중앙집중형 구조는 확장성의 한계를 드러내고 있다. 모든 NF profile과 discovery 요청이 NRF에 집중되면서 부하가 증가하고 병목이 발생하며, 대규모 네트워크 환경에서는 이를 효율적으로 확장하기 어려운 구조가 된다.

 

더불어, 현재의 NF들은 대부분 stateful 구조로 동작하여, 장애 발생 시 상태 손실 위험이 존재하고 scale-out이나 failover 과정에서 상태 동기화에 대한 추가적인 복잡성이 요구된다.

이는 클라우드 네이티브 환경에서 요구되는 탄력적 확장성과 빠른 복구를 저해하는 요인으로 작용한다.

 

결과적으로, 기존 5G SBA는 기능적으로는 유연하지만 구조적으로는 복잡하고, 확장성과 일관성 측면에서 한계를 가지는 아키텍처로 평가될 수 있다.

따라서 향후 SBA의 진화 방향은 복잡성을 줄이면서도 resilience, scalability, load balancing을 효과적으로 달성할 수 있는 단순하고 일관된 구조로의 전환에 초점을 맞춰야 한다.

 

 

 

 

“SBA 구조를 어떻게 더 단순하고 확장 가능하게 만들 것인가”

"NF resilience, scalability, load balancing을 어떻게 단순한 구조로 효과적으로 달성할 것인가"

---

Solution #1 : NF set 기반 단순화 (Resilience 통합) (Oracle, Nokia)

---

문제 인식 :  5G SBA에서는 redundancy 방식이 여러 개 공존함: NF set / NF service set / Backup AMF

이때 다음과 같은 문제가 발생함

• 서로 다른 redundancy 개념 간 중복 및 충돌 가능성
• 구현 복잡도 증가
• vendor별 지원 차이 → interoperability 문제

또한: 일부 방식은 특정 NF에만 적용되는 반면 (예: Backup AMF), 일부는 실제 deployment에서 거의 사용되지 않음

→ 전체적으로 비일관적이고 복잡한 resilience 구조

 

핵심 방향성 : Resilience 메커니즘을 NF set 하나로 통합

 

Sharing Rainy day (producer load) routing metrics

즉, 모든 NF (SCP 포함)에 동일한 redundancy 모델 적용하고 다른 redundancy 개념 제거하자

→ 단일하고 일관된 failover 구조 구축

 

2가지 축 :

1. NF set의 전면 적용 : 모든 NF를 NF set 단위로 구성하고 SCP도 SCP set 형태로 운영하자
   → 모든 NF가 동일한 방식으로 redundancy 지원
2. 기존 redundancy 개념 제거 : NF service set 제거 / Backup AMF 제거
   → redundancy 개념 단순화

동작 철학 : 

기존: “여러 redundancy 방식이 혼재된 복잡한 구조”

변경: “하나의 공통된 방식(NF set)으로 통일”

즉, 복잡성을 줄이고 일관성을 높이는 방향으로 가자

 

기대 효과 :

• 구현 단순화 / interoperability 향상 / failover 및 load balancing 일관성 확보
• vendor 간 구현 차이 감소 / 운영 및 관리 복잡도 감소

 

 

 

Solution #2 : Distributed / Hierarchical NRF (중앙 → 분산) (NTT DOCOMO)

---

문제 인식 : 기존 5G SBA에서는 NRF가 중앙 집중 구조로 동작 → 모든 NF profile을 단일 NRF가 관리

이는 다음과 같은 한계가 있다.

• NRF에 과도한 부하 집중
• scalability 한계
• single point bottleneck 발생

또한: NRF가 분산되는 경우 NF discovery/selection의 일관성 보장 어렵고,
NRF 간 정보 공유/동기화에 대한 명확한 아키텍처 정의 부족했다.

 

핵심 방향성 : NRF를 분산/계층 구조로 확장하면서도, 일관된 동작을 보장하자

즉, 중앙 NRF → multiple NRF (distributed / hierarchical)로 변환하여 NRF 간 정보 공유 및 동작 원칙 정의
→ 확장성과 일관성을 동시에 확보하자

 

2가지 축 :

1. Distributed / Hierarchical NRF 구조 도입 : 여러 NRF 인스턴스 배치 / 계층형 또는 분산형 구조 구성
   → load 분산 및 지역 기반 처리 가능
2. NRF 간 정보 공유 및 동작 규칙 정의 : NF profile / discovery 정보의 공유 / 동기화 / 접근 방식에 대한 Architecture 요구사항 정의 → 분산 환경에서도 일관된 discovery/selection 보장

 

동작 철학 : 

기존: “중앙 NRF가 모든 것을 관리”

변경: “여러 NRF가 협력하여 동작”

즉, → 중앙 집중 → 분산 협력 구조로 전환하자.

 

기대 효과 :

• NRF 부하 분산 / scalability 향상 / 장애 대응 및 resiliency 개선
• 지역/도메인 기반 최적 discovery 가능 / 대규모 6G 환경에서 운영 효율성 향상

 

 

Solution #3 : Stateless NF Architecture (상태 분리) (NTT DOCOMO)

---

문제 인식 : 기존 5G SBA에서는 NF가 UE/MM/SM context를 내부에 저장 (stateful 구조)

이는 다음과 같은 한계를 가진다.

• NF 장애 시 상태 손실 가능
• scale-out / failover 시 상태 동기화 필요 → 복잡도 증가
• vendor별로 context 구조 및 저장 방식 상이 → interoperability 문제 발생
• UDSF가 존재하지만 → NF-UDSF 간 인터페이스 및 동작 방식이 명확히 정의되지 않음 → 외부 저장소 활용이 제한적

 

핵심 방향성 : NF는 상태를 직접 저장하지 않고, 외부 저장소에서 관리하도록 하자

즉, NF = processing logic으로, 상태 = external storage (UDSF 등)로 하여 처리와 상태를 분리하자

 

Architectural overview : for NFs in scope (AMF/SMF/PCF/NRF) with external data access

3가지 축 :

1. Stateless NF + External Storage 연동 : AMF, SMF, PCF, NRF 등이 상태를 내부가 아닌 외부 저장소에서 조회/저장
   → NF는 stateless하게 동작
2. 데이터 모델 표준화 : UE/MM/SM context에 대한 → 공통 데이터 모델 정의
   → vendor 간 interoperability 확보
3. 혼합 환경 지원 (Stateful + Stateless) : 기존 stateful NF와 새로운 stateless NF가 공존 가능하도록 아키텍처 정의

 

동작 철학 : 

기존: “NF가 상태 + 처리 모두 담당 (stateful monolith)”

변경: “NF는 처리만, 상태는 외부에서 관리”

즉, → processing과 state의 분리하자

 

기대 효과 :

• NF 장애 시 빠른 복구 (state 유지됨) / scale-out / load balancing 용이 / NF 간 context 공유 가능
• vendor 간 interoperability 향상 / 클라우드 네이티브 구조에 적합