[Protocol] 5G NR Fundamental - Part 16

AF, NEF, Service Exposure와 Edge Traffic Influence

Part 15에서 PCF와 PCC Rule을 봤다면, 이번 편은 그 정책이 외부 애플리케이션의 요구사항과 어떻게 만나는지를 다룹니다. 쉽게 말해 “서비스 서버가 5GC에 어떤 힌트를 주고, 5GC가 그 힌트를 QoS·라우팅·Edge 처리에 어떻게 반영하는가”입니다.

 

목차

1. AF와 NEF가 필요한 이유
2. AF, NEF, PCF, SMF, UPF 역할 정리
3. Service Exposure 기본 흐름
4. Traffic Influence와 Edge 라우팅
5. Edge Computing에서 DNS/EASDF/DNAI가 중요한 이유
6. 메시지 흐름으로 보는 AF 요청 처리
7. 실패 원인과 로그 분석 포인트
8. FAQ
9. 3GPP 공식 참고자료

핵심 요약

• AF(Application Function)는 애플리케이션 측 요구사항을 5GC에 전달하는 역할을 한다. 예를 들어 특정 UE 트래픽을 가까운 Edge 서버로 보내고 싶다는 요청이 여기에 해당한다.
• NEF(Network Exposure Function)는 외부 AF가 5GC 기능을 직접 건드리지 못하도록 중간에서 인증, 권한 확인, 파라미터 변환, API 노출을 담당한다.
• Traffic Influence는 AF의 요청이 PCF/SMF 정책으로 반영되어 UPF 선택, UL CL, Branching Point, DNAI 기반 라우팅에 영향을 주는 흐름이다.
• Edge Computing에서는 단순히 “가까운 서버”만 보면 안 된다. DNS 응답, EASDF 동작, UE 위치, DNN/S-NSSAI, UPF 배치, 세션 연속성까지 같이 봐야 한다.

1. AF와 NEF가 필요한 이유

5G Core는 내부적으로 AMF, SMF, PCF, UPF 같은 네트워크 기능들이 서로 연동합니다.

 

그런데 실제 서비스는 코어망 내부에만 있지 않습니다.

 

게임 서버, 영상 플랫폼, 차량 관제 서버, 제조 현장의 제어 시스템처럼 네트워크 바깥에 있는 애플리케이션도 5G 품질과 라우팅에 영향을 받고 싶어 합니다.

 

예를 들어 어떤 실시간 게임 서비스가 있습니다.

 

특정 지역의 사용자가 늘어나면, 운영자는 그 UE들의 트래픽을 중앙 데이터센터가 아니라 가까운 Edge Data Network로 보내고 싶을 수 있습니다. 또는 AR 서비스가 “이 UE는 지연 시간이 중요하니 더 가까운 경로를 쓰게 해 달라”고 요청할 수도 있습니다.

 

문제는 외부 애플리케이션이 PCF나 SMF를 직접 호출하도록 열어두면 보안·권한·파라미터 검증이 매우 위험해진다는 점입니다.

 

그래서 중간에 NEF가 있습니다. NEF는 외부 세계와 5GC 사이의 안전한 출입구처럼 동작합니다.

AF 요청이 5GC 내부 정책으로 바뀌는 큰 흐름

 

NEF는 외부 AF 요청을 5GC 내부의 정책·세션 제어 흐름으로 안전하게 전달하는 관문입니다.

2. AF, NEF, PCF, SMF, UPF 역할 정리

이 주제는 약어가 많아서 처음 보면 복잡합니다. 하지만 역할을 서비스 관점으로 바꿔 보면 꽤 단순해집니다.

기능	한 줄 역할	실무적으로 보는 포인트
AF	애플리케이션 요구사항을 전달	서비스 식별자, UE 식별 정보, 위치/시간 조건, 원하는 DNAI 또는 라우팅 조건을 요청할 수 있음
NEF	5GC 기능을 외부에 안전하게 노출	AF 인증, 권한 확인, 파라미터 검증, 내부 NF로의 매핑, 이벤트 구독/알림 처리
PCF	정책 판단	AF 요청을 PCC Rule, Session Management Policy, QoS/라우팅 정책으로 반영할지 판단
SMF	PDU Session 제어	UPF 선택, N4 Rule 설정, UL CL/BP 삽입, PDU Session Modification 트리거 여부 확인
UPF	User Plane 패킷 처리	PDR/FAR/QER/URR 기반으로 실제 패킷 분류, 전달, QoS enforcement, usage reporting 수행
EASDF	Edge Application Server discovery 보조	DNS 질의/응답 처리 흐름에 개입하여 가까운 Edge Application Server 선택을 도울 수 있음

경험적으로 중요한 점
AF/NEF를 공부할 때 “외부 API가 있다” 정도로만 이해하면 로그 분석에서 막힙니다. 실제 장애는 AF 요청 자체보다 DNN, S-NSSAI, UE 식별자, DNAI, Application ID, PCF 정책 충돌, SMF의 UPF 재선택 불가 같은 조건에서 많이 갈립니다.

3. Service Exposure 기본 흐름

Service Exposure는 5GC 내부 기능을 외부 AF가 사용할 수 있도록 노출하는 개념입니다.

다만 “열어준다”는 표현은 조금 위험합니다.

 

실제로는 NEF가 외부 요청을 받아 인증과 권한을 확인하고, 필요한 경우 내부 식별자로 변환한 뒤 적절한 NF와 연동합니다.

 

대표적으로 다음과 같은 유형을 생각할 수 있습니다.

Exposure 유형	AF가 원하는 것	5GC 내부에서 확인할 것
Event Exposure	UE 위치 변화, 접속 상태, reachability 같은 이벤트 알림	구독 조건, 이벤트 ID, notification URI, 구독 만료 시간
Traffic Influence	특정 트래픽을 특정 경로 또는 Edge 쪽으로 유도	DNN/S-NSSAI, Application ID, DNAI, PCF/SMF 정책 반영 여부
Parameter Provisioning	애플리케이션 관련 정보 또는 packet flow description 제공	PFD 관리, 트래픽 분류 가능 여부, UPF 분류 룰 연동
Monitoring	특정 UE나 그룹 상태를 관찰	AF 권한, UE 식별자 매핑, privacy/consent 정책

여기서 중요한 것은 AF 요청이 곧바로 UPF 룰 변경으로 이어지는 것이 아니라는 점입니다. NEF를 통과한 요청은 정책 판단, 세션 상태, UE 위치, 현재 PDU Session 구조와 맞아야 실제 User Plane에 영향을 줍니다.

4. Traffic Influence와 Edge 라우팅

Traffic Influence는 말 그대로 애플리케이션이 트래픽 처리 방향에 영향을 주는 기능입니다.

 

예를 들어 특정 UE의 특정 애플리케이션 트래픽을 더 가까운 Edge Data Network로 보내거나, 특정 DNAI(Data Network Access Identifier)를 선호하도록 요청하는 식입니다.

 

Part 7에서 QoS Flow와 DRB 매핑을 봤고, Part 15에서 PCC Rule을 봤습니다.

 

이번에는 그 위에 “외부 서비스 요구사항”이 얹힌다고 보면 됩니다. AF는 “이 애플리케이션 트래픽은 이런 조건으로 처리해 달라”고 요청하고, PCF와 SMF는 이것을 실제 세션 정책과 UPF 경로로 바꿀 수 있는지 판단합니다.

Traffic Influence가 User Plane 경로에 반영되는 과정

 

Traffic Influence는 “모든 트래픽을 Edge로 보낸다”가 아니라, 조건에 맞는 애플리케이션 트래픽에 대해 정책 기반으로 경로 선택에 영향을 주는 기능입니다.

Traffic Influence 요청에서 자주 등장하는 조건

• Application Identifier: 어떤 애플리케이션 트래픽인지 구분하기 위한 식별자
• DNN / S-NSSAI: 어느 데이터 네트워크와 슬라이스에 속한 세션인지 확인
• DNAI: 선호하는 Data Network Access Identifier, 즉 특정 Edge 접속 지점 또는 데이터 네트워크 위치를 표현하는 데 사용
• UE 또는 Group 식별: 특정 UE, UE 그룹, 지역 조건에 따라 정책 적용 범위를 제한
• Temporal condition: 특정 시간 동안만 적용되는 정책
• Spatial condition: 특정 위치, TA, 영역에 있을 때만 적용되는 정책

5. Edge Computing에서 DNS/EASDF/DNAI가 중요한 이유

Edge Computing은 “UPF를 가까이 둔다”만으로 끝나지 않습니다.

UE가 접속할 애플리케이션 서버 주소를 어떻게 찾는지도 중요합니다.

UE가 중앙 서버의 IP를 이미 받아버리면, 네트워크가 Edge UPF를 선택해도 애플리케이션 트래픽은 중앙으로 향할 수 있습니다.

 

그래서 Edge 구조에서는 DNS 질의와 응답, EAS(Edge Application Server) discovery, EASDF(Edge Application Server Discovery Function) 같은 요소를 함께 봐야 합니다.

 

실제 현장에서 Edge 장애를 보면 “UPF는 맞게 잡혔는데 DNS가 중앙 IP를 줬다”거나 “DNS cache 때문에 이전 Edge 서버로 계속 붙는다” 같은 케이스가 생각보다 흔합니다.

항목	의미	확인 포인트
DNAI	특정 데이터 네트워크 접속 지점을 나타내는 식별자	AF 요청 DNAI와 SMF/UPF 배치 정보가 일치하는지 확인
Local UPF	Edge DN으로 가까운 경로를 제공하는 UPF	N4 PDR/FAR 변경, UL CL 또는 BP 삽입 여부 확인
EAS	Edge Application Server	UE가 실제로 어떤 서버 IP로 접속하는지 패킷과 DNS 로그로 확인
EASDF	Edge Application Server discovery 지원 기능	DNS handling rule, 응답 IP, TTL, 캐시 동작 확인
UL CL/BP	Uplink Classifier 또는 Branching Point	중앙 DN과 Edge DN으로 트래픽을 분기할 수 있는지 확인

로그를 볼 때의 감각
Edge 문제는 한 장비 로그만 보면 결론이 잘 안 납니다. AF/NEF API 요청, PCF policy decision, SMF session modification, UPF N4 rule, UE DNS query, 실제 user plane 패킷을 이어서 봐야 합니다. 어느 한 지점에서만 “정상”이라고 끝내면 원인을 놓치기 쉽습니다.

6. 메시지 흐름으로 보는 AF 요청 처리

다음은 AF가 특정 애플리케이션 트래픽을 Edge 쪽으로 유도하고 싶을 때의 일반적인 흐름입니다.

 

실제 네트워크 구현과 사업자 정책에 따라 세부 API와 내부 NF 연동은 달라질 수 있지만, 분석 관점에서는 이 순서로 보면 이해가 쉽습니다.

1. AF가 NEF로 요청: 애플리케이션 ID, 대상 UE/그룹, DNN, S-NSSAI, 선호 DNAI, 조건 정보를 포함해 요청합니다.
2. NEF가 인증·권한 확인: 이 AF가 해당 UE나 서비스에 대해 요청할 권한이 있는지 확인하고, 외부 식별자를 내부에서 사용할 수 있는 형태로 매핑합니다.
3. NEF가 PCF 또는 관련 NF로 전달: Traffic Influence 성격의 요청은 정책 판단과 연결되므로 PCF와 연동되는 경우가 많습니다.
4. PCF가 정책 결정: 기존 PCC Rule, 가입자 정책, DNN/S-NSSAI, 지역 조건, 과금 정책과 충돌하지 않는지 확인합니다.
5. SMF가 세션 반영 여부 판단: 이미 존재하는 PDU Session에 적용할지, PDU Session Modification이 필요한지, UPF 재선택이나 UL CL 삽입이 가능한지 판단합니다.
6. UPF에 N4 Rule 반영: 실제 패킷 분류와 전달은 UPF의 PDR/FAR/QER/URR 같은 룰로 반영됩니다.
7. UE 트래픽이 조건에 맞게 분기: DNS/EAS discovery 결과와 User Plane rule이 맞으면 특정 애플리케이션 트래픽이 Edge DN으로 향합니다.

AF-NEF-PCF-SMF-UPF 연동 시퀀스

 

AF 요청은 NEF에서 끝나는 것이 아니라 정책 판단, 세션 제어, N4 룰, 실제 패킷 경로까지 이어져야 의미가 있습니다.

7. 실패 원인과 로그 분석 포인트

AF/NEF/Edge 연동 장애는 “요청 실패”처럼 보이지만 원인은 여러 계층에 흩어져 있습니다.

 

아래 표는 실제 분석 시 먼저 확인할 만한 포인트입니다.

증상	가능한 원인	확인할 로그/필드
AF 요청이 NEF에서 거절	AF 인증 실패, 권한 부족, 잘못된 API path 또는 schema	HTTP status, OAuth/token, AF ID, NEF API validation error
요청은 성공했지만 정책 미반영	PCF policy conflict, 가입자 정책 미지원, DNN/S-NSSAI 불일치	PCF decision log, policy association ID, PCC Rule 변경 여부
SMF까지 전달됐지만 경로 변화 없음	UPF 재선택 불가, UL CL/BP 미지원, 세션 상태 부적합	SMF session context, N4 session modification, selected UPF
Edge UPF는 선택됐지만 중앙 서버 접속	DNS가 중앙 IP 응답, EASDF rule 미적용, UE DNS cache	DNS query/response, EASDF 로그, TTL, 실제 destination IP
특정 UE만 적용 안 됨	UE 식별자 매핑 실패, 위치 조건 불일치, roaming/permission 제한	GPSI/SUPI mapping, TA/Cell, AF subscription 대상
적용 후 품질 저하	Edge DN 용량 부족, UPF overload, 잘못된 라우팅 우선순위	UPF KPI, packet loss, latency, URR usage report, routing table

실무 로그 분석 순서

1. AF 요청 원문에서 Application ID, DNN, S-NSSAI, DNAI, 대상 UE 범위를 확인합니다.
2. NEF 응답이 단순 2xx인지, 실제 subscription/resource 생성까지 완료됐는지 봅니다.
3. PCF 정책 로그에서 AF 영향 정보가 policy decision에 들어갔는지 확인합니다.
4. SMF session context에서 해당 PDU Session에 policy update가 도착했는지 봅니다.
5. N4 메시지에서 UPF에 PDR/FAR/QER/URR 변경이 내려갔는지 확인합니다.
6. DNS/EASDF와 패킷 캡처로 UE가 실제 어떤 IP와 통신하는지 확인합니다.

8. 핵심 개념 비교 표

개념	헷갈리기 쉬운 점	기억할 표현
NEF	단순 API Gateway로만 보기 쉬움	외부 요청을 5GC 내부 정책과 이벤트로 연결하는 안전한 노출 지점
AF	항상 사업자 내부 서버라고 생각하기 쉬움	사업자 신뢰 도메인 내부 또는 외부 애플리케이션 기능이 될 수 있음
Traffic Influence	UPF 경로를 강제로 바꾸는 기능으로 오해	정책 기반으로 트래픽 라우팅에 영향을 주는 요청
DNAI	Edge 서버 IP와 동일하게 생각하기 쉬움	데이터 네트워크 접속 지점/위치를 나타내는 식별자
EASDF	UPF와 같은 User Plane 장비로 오해	Edge Application Server discovery를 위한 DNS 관련 기능
UL CL/BP	QoS Flow와 같은 개념으로 혼동	트래픽을 중앙/Edge 경로로 분기하기 위한 User Plane 구조

10. FAQ

Q1. AF가 있으면 애플리케이션이 5GC를 마음대로 제어할 수 있나요?

아닙니다.

AF 요청은 NEF와 정책 기능을 거쳐야 하며, 권한·가입자 정책·세션 상태·네트워크 지원 여부에 따라 거절되거나 일부만 반영될 수 있습니다.

 

Q2. NEF는 API Gateway와 같은 개념인가요?

겉으로는 API Gateway처럼 보일 수 있지만, 5GC 맥락에서는 단순 프록시보다 역할이 큽니다.

인증, 권한 확인, 내부 식별자 매핑, 이벤트 구독, 정책 기능과의 연결까지 담당합니다.

 

Q3. Traffic Influence가 적용되면 무조건 Edge 서버로 가나요?

그렇지 않습니다.

AF 요청은 “영향”을 주는 입력이고, 최종 경로는 PCF/SMF 정책, UPF 배치, UE 위치, DNN/S-NSSAI, DNS/EAS discovery 결과를 함께 보고 결정됩니다.

 

Q4. Edge 장애를 볼 때 가장 먼저 확인할 것은 무엇인가요?

AF 요청이 성공했는지보다, UE가 실제로 어떤 IP로 접속하는지를 먼저 확인하는 것이 빠를 때가 많습니다.

DNS 응답과 패킷의 destination IP가 Edge 서버인지 확인하면 방향이 잡힙니다.

 

Q5. DNAI는 IP 주소인가요?

아닙니다. DNAI는 Data Network Access Identifier로, 특정 데이터 네트워크 접속 지점이나 위치를 식별하는 데 사용됩니다.

실제 서버 IP나 DNS 응답과는 별개의 개념으로 보는 것이 좋습니다.

 

Q6. AF/NEF는 SA 5G에서만 의미가 있나요?

5GC의 Service Based Architecture와 강하게 연결된 개념이므로 SA 5G 맥락에서 이해하는 것이 가장 자연스럽습니다.

NSA에서는 EPC와 LTE anchor 구조가 섞이기 때문에 동일한 방식으로 설명하기 어렵습니다.

12. 3GPP 공식 참고자료

아래 문서들은 AF, NEF, Traffic Influence, Edge Computing을 볼 때 함께 참고하면 좋습니다. 버전은 사업자/프로젝트 기준에 따라 다를 수 있으므로, 실제 구현 분석에서는 해당 망이 기준으로 삼는 Release와 버전을 먼저 확인하는 것이 좋습니다.

• 3GPP TS 23.501 - System architecture for the 5G System (5GS)
• 3GPP TS 23.502 - Procedures for the 5G System (5GS)
• 3GPP TS 23.503 - Policy and charging control framework for the 5G System (5GS)
• 3GPP TS 29.522 - Network Exposure Function Northbound APIs; Stage 3
• 3GPP TS 23.548 - 5G System Enhancements for Edge Computing; Stage 2
• 3GPP TS 23.558 - Architecture for enabling Edge Applications

마무리

Part 16의 핵심은 AF와 NEF를 “외부 API”로만 보지 않는 것입니다.

 

AF 요청은 NEF를 지나 정책, 세션, UPF, DNS, Edge 서버 선택까지 이어져야 실제 사용자 경험에 영향을 줍니다.

 

그래서 로그를 볼 때도 NEF 응답 하나만 보고 끝내지 말고, PCF와 SMF, UPF, DNS/EASDF까지 연결해서 보는 습관이 필요합니다.

 

다음 Part에서는 이 흐름을 더 확장해, 네트워크가 스스로 상태를 관찰하고 정책에 반영하는 NWDAF와 Network Data Analytics를 다루면 자연스럽게 이어집니다.

 

AF/NEF가 외부 애플리케이션의 요구를 받는 창구라면, NWDAF는 네트워크 내부 데이터를 분석해 의사결정에 힌트를 주는 기능이라고 볼 수 있습니다.

 

작성 목적: 5G NR/5GC 프로토콜 학습용 정리. 실제 상용망 동작은 사업자 정책, 벤더 구현, 적용 Release, 옵션 기능 지원 여부에 따라 달라질 수 있습니다.