[6G SBA #1] 6G 표준에서 논의되는 5G SBA의 구조적 한계 총정리

6G Architecture의 핵심 이슈인 SBA Framework

---

KI#2 – SBA 프레임워크: 6G 코어 아키텍처의 핵심 진화 방향

---

 

KI#2는 6G 아키텍처에서 서비스 기반 아키텍처(SBA)를 어떻게 발전시킬 것인가에 대한 핵심 이슈다. 

5G에서 도입된 SBA는 NF 간 서비스 기반 통신 구조를 통해 유연성과 확장성을 확보했지만,

6G에서는 더 높은 수준의 효율성과 확장성, 그리고 복잡한 서비스 요구를 만족시켜야 한다.

 

이에 따라 KI#2에서는 NF 간 서비스 등록, 발견, 선택 과정을 어떻게 더 효율적으로 최적화할 수 있는지,

그리고 메시지 전달을 보다 효과적으로 수행할 수 있는 구조를 어떻게 설계할 것인지가 주요 논의 대상이 된다.

 

또한 단순한 기능 개선을 넘어, NF 서비스의 복원성(resiliency), 확장성(scalability), 효율성(efficiency), 그리고 부하 분산(load balancing)을 어떻게 향상시킬 것인지도 중요한 과제로 다뤄진다.

특히 6G 환경에서는 다양한 서비스와 트래픽 특성이 공존하기 때문에,

기존 5G보다 더 동적으로 자원을 분배하고 네트워크를 운영할 수 있는 구조가 요구된다.

 

 

 

5G SBA Framework의 구조와 한계

---

 

1. Discovery 중심 구조의 한계 → “모든 것이 discovery에 의존하는 구조”

---

 

구조적 특징

• NF 간 통신 전마다 NRF 기반 discovery 수행
• consumer가 직접 NF 선택 수행
• discovery → selection → routing이 분리된 절차

한계

• 반복적인 discovery로 인한 latency 증가
• NRF 의존 구조로 인해 병목 발생
• discovery factor 증가(170+) → selection 로직 과도한 복잡성
• roaming 시 source ↔ target 간 discovery 모델 조합 → 구현 복잡도 증가

핵심 문제 : “연결할 때마다 매번 찾는 구조”라서 비효율적

 

 

2. NF Profile 중심 구조의 한계 → “정보 모델이 너무 무겁거나, 반대로 충분히 유용하지 않음”

---

구조적 특징

• NRF에 full NF profile 저장
• consumer가 profile 기반으로 선택 수행

한계 (양 극단)

1. 정보 부족 문제
   • 동적 상태 반영 어려움 (load, congestion 등)
   • topology / cloud-native 구조 반영 부족 → 비최적 선택 발생
2. 정보 과다 문제
   • 과도한 profile 크기 → large payload
   • profile 변경 시 대량 notify → signalling storm
   • 어떤 정보를 cache해야 할지 불명확 → cache 비효율

핵심 문제 : “정보가 적어도 문제, 많아도 문제인 구조”

 

 

3. NF 간 강한 Dependency 구조 → “모든 NF가 서로를 너무 많이 알아야 하는 구조”

---

 

구조적 특징

• consumer가 producer의 상세 capability/구조 이해 필요
• NF 간 직접적인 dependency 존재
• 기능 추가 시 upstream NF 수정 필요

한계

• 새로운 NF/feature 추가 시 → 다른 NF까지 영향 확산
• multi-vendor 환경에서 → interoperability 저하
• roaming 시 → 타 네트워크 내부 정보 노출 필요

핵심 문제 : “하나 바꾸면 전체가 영향받는 구조”

 

 

4. 절차 및 signalling 구조의 비효율 → “절차가 분리되고 중복됨”

---

 

구조적 특징

• discovery → subscription → notification 분리
• 매 요청마다 discovery 수행

한계

• signalling 절차 증가
• end-to-end latency 증가
• 절차 간 중복 발생

핵심 문제 : “같은 정보를 얻기 위해 여러 번 왕복하는 구조”

 

 

5. Event 처리 구조의 한계 → “Event 기능이 NF에 과도하게 분산됨”

---

구조적 특징

• 각 NF가 EventExposure API 직접 제공
• subscription / filtering / delivery를 NF가 수행

한계

• subscription explosion
• producer NF 과부하 (fan-out 역할 수행)
• advanced 기능 부족 (replay, delivery guarantee 등)
• AI/analytics 확장 시 폭발적 증가

핵심 문제 : “이벤트가 분산되어 관리되면서 확장성이 무너짐”

 

 

 

6. 중앙 집중 구조의 한계 (NRF 중심) → “NRF가 모든 것을 알고 처리하는 구조”

---

Simplified  API  calls for an example  SBA  procedures. Source: Mayer 2018, fig. 3.

 

구조적 특징

• 모든 NF profile이 NRF에 집중
• discovery 요청이 NRF로 집중

한계

• NRF 과부하 및 scalability 한계
• single point bottleneck
• 대규모 네트워크에서 성능 저하
• distributed NRF 시 → 동기화 및 일관성 문제

핵심 문제 : “중앙 집중 구조가 확장성을 제한”

 

 

 

7. State 관리 구조의 한계 (Stateful NF) → “상태와 처리가 NF 내부에 결합됨”

---

 

구조적 특징

• UE/MM/SM context를 NF 내부에 저장

한계

• 장애 시 state 손실 가능
• scale-out 시 state 동기화 필요
• vendor 간 데이터 모델 불일치

핵심 문제 : → “state 때문에 확장성과 유연성이 제한됨”

 

 

8. Redundancy 구조의 복잡성 → “여러 redundancy 개념이 혼재”

---

구조적 특징

• NF set / NF service set / Backup AMF 공존

한계

• 개념 중복 및 충돌
• 구현 복잡도 증가
• vendor별 지원 차이

핵심 문제 : → “일관되지 않은 redundancy 모델”

 

 

9. Cloud-native 환경 미적합 → “현대 deployment 구조를 충분히 반영 못함”

---

구조적 특징

• load balancer 뒤 instance 비가시성
• HTTP/2 connection 구조 반영 부족

한계

• connection imbalance
• 실제 topology 기반 최적화 어려움

핵심 문제 : “현실적인 deployment 구조와 괴리”