[6G SBA #2] 6G SBA에서 논의되는 NF Discovery & Selection 최적화 전략

기존 5G SBA Discovery/Selection의 한계

---

5G Service-Based Architecture(SBA)는 Network Function을 유연하게 발견하고 선택할 수 있도록 설계되었지만,

실제 구현 환경에서는 여러 구조적 한계가 드러나고 있다.

 

 

우선, 현재의 NF Discovery 및 Selection은 정적이고 제한적인 NF Profile 정보에 크게 의존하고 있다.

이로 인해 load, congestion, availability와 같은 네트워크의 실시간 상태를 충분히 반영하지 못하며,

결과적으로 실제 성능이나 reachability를 고려한 최적의 NF 선택이 어려워진다.

이러한 한계는 불필요한 재시도, 지연 증가, 그리고 load imbalance로 이어진다.

 

또한, NF Profile 자체의 복잡성과 비효율성도 중요한 문제이다.

5G SBA에서는 170개 이상의 discovery factor가 정의되어 있으며,

이는 NF 간 dependency를 증가시키고 multi-vendor 환경에서 구현 난이도를 높인다.

더불어, 과도하게 상세한 NF profile 전달과 빈번한 변경 notification은 signalling overhead와 payload 증가를 초래하여 시스템 전반의 효율성을 저하시킨다.

 

 

구조적인 측면에서는 NRF(Network Repository Function) 중심의 중앙집중형 아키텍처가 병목 지점으로 작용한다.

모든 NF profile이 NRF에 집중되고, discovery 요청이 반복적으로 발생함에 따라 NRF 부하가 증가하고 scalability 문제가 발생한다. 또한, 매 요청마다 NRF를 통한 discovery 절차를 수행해야 하므로 end-to-end latency 역시 증가하게 된다.

 

마지막으로, 현재의 discovery 절차 자체가 비효율적이다.

discovery 이후 별도의 subscription 및 notification 절차가 필요하며, 이로 인해 signalling 흐름이 분리되고 복잡성이 증가한다.

캐싱 또한 어떤 정보를 유지해야 하는지 명확하지 않아, 최신성과 효율성을 동시에 확보하기 어렵다.

결과적으로, 기존 5G SBA의 NF Discovery/Selection 구조는 정확성, 효율성, 확장성 측면에서 모두 한계를 가지며, 이를 개선하기 위한 새로운 접근 방식이 요구된다.

 

 

 

 

NF/NF Service 등록 / 발견 / 선택을 어떻게 최적화할 것인가?

“어떻게 더 빠르고 효율적으로 NF를 찾고 선택할 것인가”

---

Solution #1 : NF Profile을 최적화해야 한다

---

1. NF Profile을 확장해야 한다. (Jio Platforms, Samsung)

→ “더 나은 선택을 위해 더 많은(그리고 더 좋은) 정보를 제공하자”는 접근

---

문제 인식 : 현재 5G SBA는 정적이고 제한된 NF profile 정보에 기반하여

• 동적 네트워크 상태 반영이 어렵고
• 클라우드 네이티브 구조를 충분히 표현하지 못하며
• 실제 reachability/성능을 반영하지 못함

이는 결과적으로 비효율적인 NF 선택, 지연 증가, load imbalance 문제가 발생한다.

 

핵심 방향성 : 따라서 NF discovery/selection을 개선하기 위해 NF Profile을 “정보 중심적으로 확장”해야 한다.

즉, 더 많은 정보, 더 최신의 정보, 더 구조적인 정보를 제공하여 더 정확하고 context-aware한 선택을 가능하게 해야 한다.

 

확장의 3가지 축 :

1. Capability 확장 : NF의 처리 능력, 서비스 특성 등 → “무엇을 얼마나 잘하는지”
2. Dynamic 상태 정보 : load, availability, congestion 등 → “지금 상태가 어떤지”
3. Context / Structure 정보 : topology, endpoint 구조 / service dependency / reliability / AI 기반 score 
   → “어디에 있고, 어떻게 연결되고, 실제로 잘 동작하는지”

동작 철학 : 

 

 

 

 

• 기존: → “단순 정보 제공 + consumer가 선택”
• 확장 후: → “풍부한 정보 제공 + informed / intelligent selection”

즉, NRF는 단순 registry를 넘어서 context-aware discovery 지원 역할 수행하고,

Consumer는 → 더 정교한 선택 가능해진다.

 

기대 효과 :

• NF 선택 정확도 향상 / 불필요한 재시도 및 지연 감소 / load balancing 및 scalability 개선
• cloud-native 환경 대응 / AI 기반 최적화 가능성 확보

 

 

2. NF profile을 “재구성/단순화”해야 한다. (Nokia, Hwawei, ZTE)

→ “더 빠르게 하기 위해 정보를 단순화하자”는 접근

---

문제 인식 : 이 접근은 반대로 이렇게 본다 → “문제는 정보가 부족한 게 아니라, 너무 많고 복잡하다는 것”

5G SBA의 주요 한계는 다음과 같다:

1. 과도하게 복잡한 NF profile 및 discovery :
   170개 이상의 discovery factor로 인한 NF 간 dependency 증가 및 multi-vendor 환경에서 구현 난이도 증가 
   → discovery/selection 로직 자체가 복잡해짐
2. NRF 중심 구조의 병목 : 중앙 NRF에 모든 NF profile 저장하여 대용량 profile + 높은 요청 빈도 
   → NRF 과부하 및 scalability 문제
3. 과도한 signalling 및 payload : full NF profile 전달하며, profile 변경 시 massive notification 
   → signalling storm + large payload 문제
4. 비효율적인 discovery 절차 : 매 요청마다 NRF discovery 수행하여 end-to-end latency 증가
5. 캐싱의 비효율성 : 어떤 profile을 cache해야 할지 불명확하며 cached 정보가 최적이 아닐 수 있음

핵심 방향성 : NF Profile을 줄이고, 구조를 단순화하고, 활용 방식을 최적화하자는 것

즉, 필요한 정보만 유지한 채 구조를 정리하여 discovery 자체를 줄이자 → “가볍고 빠른 시스템” 지향

 

축소의 3가지 축 :

1. NF Profile 축소 (Minimal Profile) : NRF에는 핵심 정보만 저장 (NF ID, type / slice 정보 / endpoint 정보 등)
   + 상세 정보는 필요 시 producer에서 조회 → “NRF는 index 역할만 수행”
2. Profile 구조 재구성 : discovery 요소를 구조적으로 분류 (routing 정보 / resilience 정보 / service-specific 정보) 
   → 복잡한 discovery 로직을 단순화 + distributed 구조 도입 → 중앙 NRF 의존도 감소
3. 캐싱 중심 최적화 proactive caching 유지 but → NRF가 “무엇을 cache해야 하는지” 추천 (priority-based NF list 제공 / basic 정보만 먼저 제공) → 필요 시에만 full discovery 수행

동작 철학 : 

 

 

 

 

• 기존: “많은 정보를 주고 그걸 기반으로 선택”
• 축소 후: “필요한 만큼만 주고, 나머지는 필요할 때 가져온다”

즉, NRF는 lightweight registry / Consumer/SCP는 cache 활용 / 필요 시 discovery

→ “lazy + selective discovery”

 

기대 효과 :

• NRF 부하 감소 / signalling 감소 / payload 크기 감소 / discovery latency 감소
• scalability 향상 / multi-vendor 환경에서 구현 단순화

 

 

 

Solution #2 : NF Discovery 및 Selection 절차를 더 Efficient하고 Scalabe하게!

---

1. Discovery/Selection의 책임을 이동하자 (Delegation 기반) (Nokia, Hwawei)

→ NF discovery 및 selection을 Consumer에서 네트워크 내부(Target/Producer 측)로 이동시켜 구조 단순화 + 효율 향상

---

문제 인식 : 기존 5G SBA에서는 다음과 같은 한계가 있다.

1. NF consumer가 discovery/selection에 깊게 관여 → inter-NF dependency 증가
2. NRF 기반 discovery 절차 반복 → 추가 signalling 및 latency 발생
3. roaming 환경에서 source ↔ target 간 NF profile 교환 필요 (이때 다양한 discovery 모델 조합 존재)
   → 구현 복잡도 증가 및 interoperability 문제
4. 중앙 NRF 의존 구조 → scalability 문제 + 병목 발생

핵심 방향성 : “선택은 요청을 받는 쪽(타겟 네트워크/프로듀서 측)에서 수행”

 

 

즉, consumer는 “요구조건”만 전달하고 실제 selection은 target PLMN의 SCP 또는 producer 측에서 수행

또한 NF profile 교환 대신 → capability 수준 정보만 교환하자

 

3가지 축 :

1. Selection 위치 이동 (Target-side selection) :
   NF selection을 항상 target PLMN에서 수행 / SCP가 selection의 핵심 역할 수행
   → roaming에서도 일관된 selection 구조 확보
2. Discovery 절차 제거/축소 : consumer ↔ NRF 실시간 discovery 최소화 / discovery를 “delegated decision”으로 전환
   → message forwarding 경로 단순화
3. 정보 교환 방식 변경 (Profile → Capability) : NF profile 교환 제거, 대신 PLMN capability (DNN, NSSAI 등)만 공유
   → 내부 토폴로지/상태 은닉 → signalling 감소

동작 철학 : 

• 기존: → “consumer가 정보를 받아 직접 선택”
• 변경: → “consumer는 요청만 정의하고, 선택은 네트워크 내부가 수행”

즉, consumer: lightweight requester / network(SCP/producer): decision maker 
→ control의 중심을 network 내부로 이동

 

기대 효과 :

• inter-NF dependency 감소 / roaming 절차 단순화 / NF 내부 구조 및 topology 은닉
• signalling 및 latency 감소 / NRF 부하 감소 및 scalability 향상 / multi-vendor 환경에서 구현 용이성 증가

 

 

2. SCP 중심의 지능형 Routing/Selection (Nokia, Jio Platforms)

→ SCP를 중심으로 routing 및 NF selection을 지능화하여 최적의 경로와 NF를 선택하도록 하자

---

문제 인식 : 기존 5G SBA에서는 다음과 같은 한계가 있었다.

• SCP는 단순 forwarding/relay 역할에 가까움 → routing 최적화 기능 부족
• SCP 간 / SCP-NF 간 상태 정보 공유 부재 → 네트워크 전체 상태를 고려한 선택 불가능
• cloud-native 환경에서 load balancer 뒤의 instance 구조 비가시성 & HTTP/2 connection 특성으로 인한 비효율
  → connection imbalance 및 비최적 routing 발생
• routing은 대부분 static하거나 deterministic → congestion / failure 상황에 느리게 대응

 

핵심 방향성 : SCP를 “네트워크 상태를 인지하고 최적 결정을 내리는 핵심 노드”로 확장

즉, SCP가 상태 정보를 수집하여 이를 공유하고 이를 기반으로 routing/selection 수행하자

또한 필요 시 AI까지 활용하여 → predictive routing 가능하게 하자

 

3가지 축 :

1. Routing metric 공유 : SCP 간 / SCP ↔ NF 간 load / delay / error rate 등을 공유
   → 네트워크 상태에 대한 global visibility 확보
2. Topology-aware & 구조 인지 : topology domain 정보 활용해 internal/external endpoint 구분 + endpoint 수 및 capacity 반영 → cloud-native 환경에서 실제 deployment 구조를 반영한 routing 가능
3. AI 기반 routing : 외부 AI (Routing Advisor) 활용해 prediction + TTL 기반 hint 제공하고 SCP가 이를 정책적으로 활용하자 → predictive / proactive routing

동작 철학 : 

• 기존: “정해진 규칙 기반 routing (static/deterministic)”
• 변경: “상태 + 예측 기반 routing (dynamic/intelligent)”

즉, SCP = 단순 proxy ❌ / SCP = decision engine ⭕ → 네트워크 상태를 학습하고 최적 경로를 선택

 

기대 효과 :

• NF selection 정확도 향상 / routing 지연 및 재시도 감소 / load balancing 개선
• 네트워크 혼잡/장애에 대한 빠른 대응 / cloud-native 환경에서 효율적인 connection 관리 / AI 기반 최적화 가능

 

 

3. 기존 절차 유지 + 최적화 (Ericsson) 

→ 기존 5G SBA discovery 절차를 유지하면서, 불필요한 절차를 제거하고 signalling을 줄이자

---

문제 인식 : 기존 5G SBA에서는 다음과 같은 한계가 있다.

• NF discovery 이후 별도의 NF status subscription 절차 필요. 즉, discovery + subscription (추가 절차)
  → signalling 절차 증가 / latency 증가 / 구현 복잡도 증가
• NF 상태 변화를 반영하기 위해 → 추가적인 subscribe/notify 흐름 필요 → 절차가 비효율적으로 분리됨

핵심 방향성 : discovery와 subscription을 통합하여 절차를 단순화하자

discovery 요청 시 → subscription까지 함께 처리 → 추가 signalling 절차 제거

 

2가지 축 :

 

1. Implicit subscription 도입 : NF consumer가 discovery 시 Notification endpoint 포함
   →  NRF는 자동으로 해당 NF들에 대해 subscription 수행 → explicit subscription 절차 제거
2. Discovery-Notification 통합 : discovery 결과와 함께 subscription ID 제공
   → 이후 NF 상태 변경 시 자동 notify → 별도 subscription setup 필요 없음

동작 철학 : 

• 기존: → “각 기능을 분리해서 처리 (discovery → subscription)”
• 변경: → “한 번에 처리 (discovery = subscription 포함)”

즉, 절차를 줄이고 흐름을 단순화

 

기대 효과 :

• signalling 절차 감소 / discovery latency 감소
• NF 상태 동기화 효율 향상 / 구현 복잡도 감소 / 전체 discovery 절차 경량화