[Protocol] 5G NR Fundamental - Part 17

UL CL, Local Breakout, Edge UPF와 Traffic Steering

Part 16에서 AF와 NEF를 통해 애플리케이션 요구사항이 5GC 안으로 들어오는 흐름을 봤다면, 이번에는 그 요구가 실제 사용자 트래픽 경로를 어떻게 바꾸는지 살펴볼 차례입니다.
같은 PDU Session이라도 트래픽이 중앙 데이터센터로 갈 수도 있고, 가까운 Edge 쪽 UPF로 빠질 수도 있습니다.
 
그 갈림길에 있는 개념이 UL CL, Local Breakout, Edge UPF, Traffic Steering입니다.
 
핵심 요약

• Local Breakout은 사용자 트래픽을 중앙망까지 끌고 가지 않고 가까운 로컬 DN이나 Edge Application Server 쪽으로 빼는 구조입니다.
• UL CL(Uplink Classifier)은 업링크 패킷을 보고 어떤 트래픽은 중앙 PSA UPF로, 어떤 트래픽은 로컬 PSA/Edge UPF로 보내도록 나누는 역할로 이해하면 쉽습니다.
• SMF는 UPF 선택과 경로 제어의 중심에 있고, 실제 패킷 처리 규칙은 PFCP를 통해 UPF에 내려갑니다.
• AF/PCF는 서비스 요구사항을 정책으로 반영하고, SMF는 그 정책과 구독 정보, 위치, DNAI 등을 보고 사용자 평면 경로를 잡습니다.
• 로그를 볼 때는 “PDU Session이 만들어졌는가”보다 “어느 UPF가 Anchor이고, 어느 트래픽이 어디로 빠졌는가”를 같이 봐야 합니다.

이번 글에서 다룰 내용

1. 왜 5G에서 트래픽 경로가 중요해졌는가
2. PSA UPF, UL CL, Branching Point, Edge UPF 구분
3. Local Breakout이 동작하는 기본 그림
4. Traffic Steering 판단에 들어가는 정보
5. SMF가 UPF에 규칙을 내려주는 흐름
6. Edge Application 접속과 DNS/EASDF 관점
7. 실무 로그에서 확인할 포인트
8. FAQ

1. 왜 트래픽 경로까지 신경 써야 할까?

LTE를 처음 공부할 때는 “단말이 망에 붙고, 베어러가 생기고, 인터넷이 된다” 정도로 흐름을 잡아도 큰 그림을 이해하는 데 무리가 없었습니다.
 
그런데 5G Core로 넘어오면 이야기가 조금 달라집니다.
 
같은 인터넷 접속처럼 보여도, 실제 사용자 데이터가 어느 UPF를 지나 어느 Data Network로 나가는지가 서비스 품질에 직접 영향을 줍니다.
 
예를 들어 AR 스트리밍, 공장 제어, 클라우드 게임처럼 지연시간에 민감한 서비스는 중앙 데이터센터까지 왕복하는 경로가 부담이 될 수 있습니다.
 
이럴 때 트래픽을 사용자와 가까운 Edge 쪽으로 빼면 왕복 지연을 줄이고 전송망 부하도 낮출 수 있습니다.
3GPP의 Edge Computing 설명에서도 코어 네트워크와 클라우드 기능을 사용자 가까운 네트워크 엣지로 이동시키는 개념을 핵심으로 설명합니다.
 
그래서 5G에서는 PDU Session 하나만 보는 것이 아니라, 그 세션 안에서 어떤 트래픽이 어느 경로로 빠지는지까지 같이 봐야 합니다.
 
이때 등장하는 대표적인 키워드가 UL CL, Local Breakout, Edge UPF, Traffic Steering입니다.

2. 먼저 용어를 사람 말로 정리해보자

이 주제는 약어가 많아서 처음 보면 꽤 딱딱합니다.
 
하지만 실제로는 “패킷이 어느 길로 나갈지 정하는 구조”라고 보면 훨씬 편합니다.
 
아래 표처럼 역할을 나눠두면 이후 절차가 덜 헷갈립니다.

용어	간단히 말하면	로그에서 볼 때의 감각
PSA UPF (PDU Session Anchor)	PDU Session의 Anchor 역할을 하는 UPF입니다. UE IP 주소와 Data Network 연결의 기준점이 됩니다.	“이 세션의 기본 출구가 어디인가?”를 볼 때 먼저 확인합니다.
UL CL (Uplink Classifier)	업링크 패킷을 분류해서 중앙 경로와 로컬 경로로 나눠 보내는 기능입니다.	특정 목적지 IP, FQDN, App ID, 5-tuple 기준으로 경로가 갈라지는지 봅니다.
Branching Point	IPv6 multi-homing 같은 구조에서 트래픽을 여러 PSA로 분기하는 포인트입니다.	UL CL과 비슷해 보이지만 세션 구조와 IP anchoring 관점이 다릅니다.
Edge UPF	사용자 가까운 위치에 배치된 UPF입니다. Edge Application Server 쪽 DN과 가까운 경우가 많습니다.	지연시간, 지역성, 로컬 서비스 접속 문제를 볼 때 중요합니다.
DNAI	Data Network Access Identifier입니다. 어떤 로컬 DN 접속 지점인지 구분하는 힌트로 쓰입니다.	AF 영향 라우팅, Edge 접속 위치, SMF의 UPF 선택 근거를 따라갈 때 등장합니다.

3. 기본 구조: 중앙으로 갈 트래픽과 Edge로 빠질 트래픽

Local Breakout을 이해할 때 가장 쉬운 그림은 “모든 패킷이 한 길로 가지 않는다”는 것입니다.
일반 인터넷 트래픽은 중앙 PSA UPF를 통해 나가고, 특정 Edge 서비스 트래픽은 가까운 Edge UPF 또는 로컬 PSA 쪽으로 빠질 수 있습니다.

UL CL은 업링크 트래픽을 분류해 중앙 경로와 로컬 경로로 나누는 지점으로 이해하면 쉽습니다.

 
여기서 중요한 점은 Edge 경로가 “새로운 인터넷”처럼 따로 생기는 것이 아니라는 점입니다.
UE 입장에서는 여전히 PDU Session을 사용합니다.
다만 네트워크 내부에서 SMF와 UPF가 트래픽별 처리 규칙을 적용하면서 일부 흐름이 로컬 DN으로 빠집니다.

4. SMF는 무엇을 보고 경로를 정할까?

SMF가 UPF를 고르고 경로를 정할 때는 단순히 “가장 가까운 장비”만 보는 것이 아닙니다.
가입자의 허용 서비스, DNN/S-NSSAI, UE 위치, 정책, AF가 전달한 서비스 요구사항, UPF의 지원 기능, DNAI 같은 정보가 함께 들어갑니다.
 
현장에서 장애를 볼 때도 이 관점이 중요합니다.
 
Edge 서버는 살아 있고 UE도 인터넷은 되는데, 정작 특정 서비스만 중앙망을 돌아가는 경우가 있습니다.
이런 상황에서는 무선 품질보다 SMF의 UPF 선택, PCF 정책, AF Traffic Influence, DNS 응답, F-TEID/PFCP 규칙 쪽을 먼저 봐야 할 때가 많습니다.

판단 요소	왜 필요한가	문제가 생기면 보이는 현상
DNN / S-NSSAI	어떤 데이터 네트워크와 슬라이스를 사용할지 정합니다.	세션은 생성되지만 Edge 대상 정책이 적용되지 않을 수 있습니다.
UE Location	현재 UE가 어느 지역, 어느 접속망 근처에 있는지 판단합니다.	이동 후에도 기존 중앙 경로를 유지하거나 잘못된 Edge로 붙을 수 있습니다.
DNAI	로컬 DN 접속 지점을 구분하는 힌트로 쓰입니다.	AF가 의도한 Edge 경로와 실제 SMF 선택이 어긋날 수 있습니다.
PCF Policy	서비스별 라우팅, QoS, 과금 정책을 반영합니다.	특정 앱만 지연이 크거나 QoS가 기대와 다르게 적용됩니다.
UPF Capability	해당 UPF가 UL CL, PSA, 로컬 접속 기능을 지원하는지 봅니다.	후보 UPF는 있어 보이지만 실제 경로 구성에 실패할 수 있습니다.

5. Control Plane에서는 어떤 일이 벌어질까?

사용자 패킷은 UPF를 지나가지만, 그 UPF가 마음대로 패킷을 나누는 것은 아닙니다.
 
경로 제어의 시작점은 SMF입니다. SMF는 정책과 세션 정보를 바탕으로 UPF를 선택하고, PFCP 기반으로 패킷 처리 규칙을 내려줍니다.
이 규칙에는 어떤 패킷을 감지할지, 어떤 터널로 보낼지, 어느 쪽으로 forwarding할지 같은 내용이 들어갑니다.

Traffic Steering은 AF 요청 하나로 끝나지 않고, NEF/PCF/SMF/UPF가 이어지는 제어 흐름으로 봐야 합니다.

 
실무 로그에서는 PFCP Session Establishment/Modification 쪽을 보면 힌트가 많습니다.
PDR(Packet Detection Rule), FAR(Forwarding Action Rule), QER(QoS Enforcement Rule), URR(Usage Reporting Rule) 같은 규칙이 어떤 조건으로 만들어졌는지 보면, 실제 트래픽 경로가 왜 그렇게 잡혔는지 추적할 수 있습니다.

6. Edge 접속에서 DNS가 자주 등장하는 이유

Edge Application Server에 접속할 때 단말이 처음부터 “나는 어느 Edge 서버로 가야 한다”고 아는 경우는 많지 않습니다.
 
보통은 앱이 도메인 이름으로 접속하고, DNS 응답을 통해 실제 IP 주소를 얻습니다.
 
이때 Edge 환경에서는 UE 위치나 서비스 정책에 따라 가까운 Edge Application Server 주소를 주는 것이 중요합니다.
 
3GPP Edge Computing 문서에서는 EASDF(Edge Application Server Discovery Function) 같은 기능도 함께 다룹니다.
 
단순히 UPF만 가까이 둔다고 끝나는 것이 아니라, 앱이 실제로 가까운 서버 IP를 받아야 하고, 그 IP로 향하는 트래픽이 Local Breakout 경로를 타야 전체 그림이 맞습니다.

Edge 서비스는 DNS/EASDF와 UPF 경로 제어가 함께 맞아야 사용자가 가까운 서버로 붙습니다.

7. 로그 분석 시 확인 포인트

UL CL이나 Local Breakout 문제는 겉으로 보면 단순 인터넷 장애처럼 보일 수 있습니다.
 
하지만 세션은 정상이고, 일반 웹도 되는데, 특정 앱만 느리거나 특정 지역에서만 Edge로 붙지 않는 식으로 나타나는 경우가 많습니다.
 
그래서 로그를 볼 때는 아래 순서로 좁혀가는 편이 좋습니다.

확인 지점	봐야 할 내용	힌트
PDU Session	DNN, S-NSSAI, UE IP, SSC Mode, Anchor UPF	세션 자체가 기대한 서비스용으로 만들어졌는지 먼저 봅니다.
SMF Decision	선택된 UPF, UL CL 삽입 여부, PSA 변경 여부	SMF가 어떤 이유로 특정 UPF를 선택했는지 로그 메시지를 확인합니다.
PFCP Rule	PDR/FAR/QER/URR, Outer Header Creation, F-TEID	실제 패킷 forwarding 방향은 PFCP 규칙에 흔적이 남습니다.
DNS/EASDF	도메인 질의, 응답 IP, Edge 서버 선택	DNS가 중앙 서버 IP를 줬다면 UPF가 가까워도 Edge 효과가 약합니다.
N6/N9 경로	UPF 간 터널, 로컬 DN 연결, 방화벽/라우팅	제어 평면은 성공했는데 사용자 패킷만 막히면 이 구간을 봅니다.
이동성	UE 이동 후 경로 갱신, PSA/UL CL 재선택	이동 후에도 이전 Edge에 붙어 있으면 지연이 커질 수 있습니다.

개인적으로 이 주제를 볼 때는 “UPF가 몇 대인가?”보다 “어떤 패킷이 어느 UPF를 지나갔는가?”를 먼저 묻는 편이 훨씬 빠릅니다. 장비 이름만 보고는 경로가 보이지 않습니다. PDR과 FAR까지 내려가야 실제 길이 보입니다.

8. 자주 헷갈리는 부분

UL CL과 PSA는 같은가?

같지 않습니다.
PSA는 PDU Session의 Anchor 역할에 초점이 있고, UL CL은 업링크 패킷을 분류해 경로를 나누는 기능에 초점이 있습니다.
구현이나 배치에 따라 같은 UPF 장비 안에 기능이 함께 있을 수는 있지만, 개념적으로는 역할을 분리해서 보는 편이 좋습니다.

Local Breakout이면 무조건 지연시간이 줄어드나?

항상 그렇지는 않습니다.
로컬 UPF와 Edge 서버가 가까워도 DNS가 중앙 서버를 주거나, 로컬 DN 라우팅이 돌아가거나, 방화벽 정책이 비효율적이면 기대만큼 좋아지지 않습니다.
Local Breakout은 경로를 짧게 만들 수 있는 구조이지, 그 자체가 성능 보장을 의미하지는 않습니다.

AF가 요청하면 SMF가 반드시 그대로 따르나?

아닙니다.
AF의 요구사항은 정책 판단의 입력으로 들어갈 수 있지만, 최종적으로는 가입자 권한, 운영자 정책, 네트워크 상태, UPF 지원 여부, 위치 정보 등을 함께 보고 결정됩니다.
그래서 AF 요청 로그만 보고 “Edge 경로가 적용됐다”고 단정하면 안 됩니다.

FAQ

Q1. UL CL은 반드시 Edge Computing에서만 쓰이나요?
A. Edge Computing과 자주 함께 언급되지만, 본질은 업링크 트래픽 분류와 경로 선택입니다.
특정 트래픽을 다른 PSA나 로컬 DN으로 보내야 하는 구조에서 의미가 있습니다.
 
Q2. Edge UPF가 있으면 UE가 별도 IP를 받나요?
A. 구조에 따라 다릅니다.
단일 PDU Session 안에서 UL CL로 트래픽만 분기할 수도 있고, IPv6 multi-homing이나 다른 세션 구조가 쓰일 수도 있습니다. 그래서 UE IP 하나만 보고 전체 경로를 판단하면 부족합니다.
 
Q3. N6와 N9는 어떻게 구분하면 되나요?
A. N6는 UPF와 Data Network 사이의 사용자 평면 인터페이스로 보면 됩니다.
N9는 UPF와 UPF 사이의 사용자 평면 연결입니다.
Local Breakout 구조에서는 N3, N6, N9가 어떻게 이어지는지 확인하는 것이 중요합니다.
 
Q4. 장애 분석에서 가장 먼저 볼 로그는 무엇인가요?
A. PDU Session Establishment/Modification, SMF의 UPF 선택 로그, PFCP Session Establishment/Modification, DNS 응답, N6/N9 라우팅 순서로 보는 편이 좋습니다.
일반 인터넷은 되는데 특정 Edge 서비스만 느리면 DNS와 PFCP 규칙을 특히 먼저 확인합니다.
 
Q5. Part 16의 AF/NEF와 이번 Part 17은 어떻게 이어지나요?
A. Part 16은 애플리케이션 요구사항이 NEF를 통해 5GC 정책 영역으로 들어오는 입구를 봤습니다.
Part 17은 그 요구가 SMF와 UPF 제어로 이어져 실제 사용자 패킷 경로를 바꾸는 부분을 봅니다.

3GPP 공식 참고자료

• 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
• 3GPP TS 23.548 - 5G System Enhancements for Edge Computing; Stage 2
• 3GPP TS 29.522 - 5G System; Network Exposure Function Northbound APIs
• 3GPP TS 29.244 - Interface between the Control Plane and the User Plane nodes

마무리

Part 17의 핵심은 “5G에서 데이터 경로는 고정된 한 줄이 아니다”라는 점입니다.
UE는 하나의 서비스처럼 느끼지만, 5GC 내부에서는 정책과 위치, 서비스 요구사항에 따라 트래픽 경로가 달라질 수 있습니다.
UL CL은 그 분기점에 있고, Local Breakout은 사용자를 가까운 Edge 서비스로 보내기 위한 대표적인 구조입니다.
 
다음 파트에서는 이 흐름을 이어서 ATSSS, Multi-access PDU Session, Wi-Fi와 5G 동시 경로 제어 쪽으로 확장하면 자연스럽습니다. Edge와 Local Breakout이 “어느 UPF로 갈 것인가”의 문제였다면, ATSSS는 “어느 Access를 어떻게 조합할 것인가”에 가까운 주제입니다.