네트워크 슬라이싱의 ‘종단간 보장’은 어디까지 가능한가

Network Slice와 Network Slice Subnet이 가리키는 범위

3GPP TS 28.530은 Network Slice를 특정 서비스 특성을 지원하기 위해 정해진 네트워크 능력과 특성을 제공하는 논리 네트워크로 다룬다. 관리 관점의 Network Slice Instance는 사업·운영 목적에 필요한 Network Function과 지원 자원을 묶고, ServiceProfile로 표현되는 서비스 수준 요구와 연결된다. 여기에는 lifecycle 준비, commissioning, operation, decommissioning 같은 관리 단계가 따른다.

Network Slice Subnet은 Network Slice의 일부 또는 전부를 이루는 Network Function과 자원의 묶음이다. 독립적으로 관리할 수 있으며 Core Network만, Access Network만, 또는 여러 도메인의 조합으로 구성될 수 있다. 한 subnet이 하나의 slice에만 쓰일 수도 있고 여러 slice가 직접 또는 간접으로 공유할 수도 있다. 물리 자원, 논리 자원, 가상 자원이 모두 구성 요소가 될 수 있다.

이 정의는 “slice 하나마다 모든 장비가 물리적으로 전용”이라는 뜻이 아니다. Network Slice는 shared subnet이나 shared Network Function을 사용할 수 있고, isolation 요구도 관리 profile과 실제 자원 배치로 구체화해야 한다. SliceProfile은 subnet에 적용할 요구를 나타내고, ServiceProfile은 서비스 수준 요구를 관리 모델에 전달하는 역할을 한다. profile이 존재한다는 사실과 실제 구간이 목표를 만족한다는 사실은 구분해야 한다.

또 하나의 핵심 경계는 transport다. TS 28.530은 3GPP 관리 시스템이 Core Network와 Access Network 부분을 직접 관리할 수 있지만, non-3GPP transport나 data network를 항상 직접 관리하는 것은 아니라고 설명한다. 대신 필요한 topology, 연결, QoS, link capacity 요구를 다른 도메인의 관리 시스템에 전달하고 조정한다. 애플리케이션 서버도 Network Slice 관리 대상과 고객 서비스 끝점이 자동으로 같은 것은 아니다. 3GPP의 end-to-end 관리 모델은 여러 관리 도메인을 조정하는 틀이지, 모든 외부 구간을 한 사업자가 직접 제어한다는 선언이 아니다.

TS 28.531은 이 개념을 실제 provisioning 절차로 이어 간다. Network Slice Instance를 만들 때 새 subnet을 만들거나 기존 subnet을 재사용하고, 연관 관계를 구성할 수 있다. 운영 중에는 요구 변화나 성능 supervision 결과에 따라 capacity, topology, configuration을 수정할 수 있다. feasibility check와 reservation 절차도 제공된다. 그러나 절차가 있다는 사실만으로 모든 RAN·transport·cloud 자원이 예약됐거나 고객 SLA가 성립했다고 볼 수는 없다. 무엇을 예약했고 언제까지 유지하며 실패 시 무엇을 할지는 실제 배포와 계약에서 정해야 한다.

표준 기능과 사업자 책임은 구간마다 다르다

두 표의 ‘표준 기능’은 사용할 수 있는 절차와 정보 모델을 뜻한다. ‘사업자 책임’은 그 기능을 어느 장비와 소프트웨어 조합으로 구현하고, 어떤 목표와 정책을 적용하며, 장애 때 누가 조치할지를 뜻한다. 예를 들어 RAN이 S-NSSAI를 인지해도 특정 slice에 PRB를 항상 전용 배정해야 한다는 보편 규칙은 아니다. 사업자는 traffic 특성, spectrum, scheduler, 우선순위, admission과 다른 slice의 영향을 함께 설계해야 한다.

단말도 passive endpoint가 아니다. 앱이 의도한 traffic이 올바른 PDU Session과 QoS Flow로 들어갔는지 확인하려면 OS의 routing, modem 동작, policy version, endpoint 계측이 맞아야 한다. 표준 UE 기능을 지원한다는 설명만으로 특정 모델과 앱의 상용 동작을 일반화할 수 없다.

애플리케이션 구간에서는 제어권이 더 분명히 갈릴 수 있다. 사업자가 제공하는 managed edge나 communication service라면 server-side telemetry와 KQI를 계약 범위에 포함할 수 있다. 일반 OTT 서비스라면 네트워크 사업자가 애플리케이션 내부 queue, database, rendering time을 보지 못할 수 있다. GSMA NG.116도 KQI를 end-to-end 서비스 성능·품질, KPI를 네트워크 성능으로 구분하고, OTT 서비스 KQI는 network provider가 접근하지 못할 수 있음을 명시한다.

KPI는 이름보다 측정 경계를 먼저 봐야 한다

Latency는 “어디부터 어디까지, 어느 방향으로, 어떤 packet과 통계로 측정했는가”가 붙어야 의미가 있다. 3GPP TS 28.554의 Network Slice 평균 end-to-end uplink·downlink delay는 UE와 PSA UPF 사이를 대상으로 한다. uplink는 UE에서 RLC SDU가 scheduling된 때부터 PSA UPF가 GTP PDU를 받은 때까지, downlink는 PSA UPF가 GTP PDU를 보낸 때부터 UE가 RLC SDU를 받은 때까지를 다룬다. 이름에 end-to-end가 들어가도 애플리케이션 서버 응답시간까지 포함한다고 읽으면 안 된다.

Throughput도 측정점이 중요하다. TS 28.554의 slice upstream·downstream throughput은 N3에서 관측한 octet을 기반으로 계산할 수 있다. 이것은 5G user-plane 전달 능력을 보는 데 유용하지만, 단말 앱의 유효 payload 처리량이나 서버가 처리한 업무 transaction 수와 같지 않다. protocol overhead, retransmission, application pacing, server bottleneck이 그 사이에 있다.

Packet loss는 한 숫자로 합치기 전에 Uu, N3, F1-U 같은 구간별 측정을 나눠 봐야 한다. TS 28.552는 interface별 loss와 delay 측정을 제공해 손실이 어느 구간에서 생겼는지 좁힐 수 있게 한다. UE에서 서버까지의 손실률을 알고 싶다면 network 구간 측정에 endpoint sequence나 application transaction 결과를 더해야 한다. 각 수집기가 사용하는 denominator, sampling interval, duplicate·late packet 처리 방식도 같아야 한다.

Jitter는 더욱 경계가 필요하다. 흔히 packet delay variation을 뜻하지만 TS 28.554의 slice KPI 표에 ‘jitter’라는 이름 하나가 모든 구간을 대표하도록 정의돼 있지는 않다. ITU-T Y.1540처럼 IP performance를 ingress와 egress 측정점 사이의 packet delay variation으로 정의한 자료를 사용하고, 어느 두 점의 variation인지 명시해야 한다. radio scheduling variation, transport queue variation, server processing variation을 한 구간 값으로 대신할 수 없다.

Availability와 reliability도 동일하지 않다. Availability는 약속한 시간 중 서비스나 자원이 사용할 수 있었던 비율로 정의할 수 있지만, cell availability, Network Slice availability, PDU Session 성공, 애플리케이션 transaction 성공은 서로 다른 관측 대상이다. Reliability는 정해진 시간·조건 안에 packet이나 업무가 성공할 확률로 다룰 수 있다. TS 28.554의 URLLC end-to-end reliability KPI도 Uu와 N3 범위를 결합한 정의가 있으므로, 일반 애플리케이션의 업무 성공률까지 자동 포함하지 않는다.

평균값만으로 SLA를 판단하는 것도 위험하다. 평균 지연이 낮아도 tail latency가 크면 제어 명령 deadline을 놓칠 수 있다. p95·p99 또는 규격이 정한 bin·분포, 연속 위반 시간, 측정 표본 수, 유지보수 제외 조건, 관측 불가 처리 원칙이 필요하다. 처리량도 평균이 아니라 minimum sustained rate나 busy-hour 기준일 수 있고, availability도 분모에서 무엇을 제외했는지에 따라 의미가 달라진다.

결국 고객 SLA는 여러 측정 경계의 합성 규칙을 별도로 가져야 한다. UE↔PSA UPF KPI가 정상이고 application KQI가 나쁘다면 UPF 이후 data network나 server를 봐야 한다. 반대로 application server가 정상인데 UE KQI가 나쁘다면 RAN·transport·core 구간을 좁혀야 한다. 단일 구간 수치는 원인 위치를 찾는 증거이지, 그 자체로 전체 서비스 SLA의 충족 증명은 아니다.

Isolation과 전용 자원은 같은 약속이 아니다

Isolation은 다른 slice나 tenant의 fault, congestion, security event가 목표 slice에 미치는 영향을 정해진 수준으로 제한하려는 요구다. Dedicated resource는 특정 자원을 한 slice에만 배치하는 선택이고, shared resource는 여러 slice가 같은 자원을 쓰되 정책과 quota로 구분하는 선택이다. 둘은 관련 있지만 같은 말은 아니다.

전용 UPF를 배치해도 RAN spectrum과 transport link, cloud fabric, power와 operations tool을 공유하면 다른 구간의 영향이 남는다. 반대로 shared compute를 사용해도 CPU quota, queue, namespace, admission, scaling과 fault domain을 검증해 필요한 isolation을 달성할 수 있다. “dedicated”라는 자산 명칭만으로 종단간 isolation 수준이 증명되지 않고, “shared”라는 이유만으로 보장이 불가능하다고 단정할 수도 없다.

3GPP TS 28.541의 isolation group과 isolation profile은 managed resource type별 isolation 요구를 표현하고 Network Slice 또는 Subnet과 연결할 수 있게 한다. 하지만 profile을 실제 scheduler, queue, VM/container, UPF, transport policy로 변환하는 것은 배포 책임이다. vendor마다 resource model과 telemetry가 다를 수 있으므로 동일한 profile이 같은 물리 동작을 만들었는지 시험해야 한다.

Admission control은 새 부하를 받아들일지 판단하는 문지기다. TS 23.501의 Network Slice Admission Control은 slice별 등록 UE 수와 PDU Session 수가 설정한 최대값을 넘지 않게 제어할 수 있다. 이는 overload를 제한하는 중요한 수단이지만, 이미 받아들인 session의 radio quality, transport delay, server compute를 종단간 예약한다는 뜻은 아니다. UE 수가 한도 아래여도 traffic mix와 packet size, mobility, server load에 따라 성능은 달라질 수 있다.

Capacity reservation은 특정 시간과 구간에 자원을 확보하는 배포 행위다. TS 28.531의 reservation·feasibility 절차는 요구를 확인하고 자원 준비를 조정할 수 있게 하지만, 어느 도메인의 어떤 자원을 얼마만큼 잡았는지 확인해야 한다. Core compute만 예약하고 spectrum이나 transport queue를 예약하지 않았을 수 있고, 낮 시간 예약이 busy hour에도 유효하다고 볼 수 없다. 예약 후 topology 변경이나 failure reroute가 생겼다면 새 경로에서도 목표가 유지되는지 다시 검증해야 한다.

이 네 용어를 구분하면 보장 조건이 선명해진다. Isolation은 영향 제한의 목표, dedicated/shared는 자원 소유·사용 방식, admission control은 새 요청 수용 정책, reservation은 미래 또는 현재 capacity 확보 행위다. 하나를 도입했다고 나머지가 자동으로 따라오지 않는다. 상용 SLA는 필요한 조합과 검증 방법, 예외와 복구 조건을 명시해야 한다.

Assurance는 여러 구간의 측정을 다시 연결하는 고리다

대체 설명 단말·애플리케이션 클라이언트에서 RAN, 전송망, 5G Core, 애플리케이션 서비스로 이어지는 전달 경로를 구간별로 측정한다. 운영 계층은 같은 식별자와 시간축으로 KPI·KQI를 연결해 목표 위반 구간을 좁히고, 조치 뒤 동일한 endpoint에서 재검증한다. 이는 설명용 개념도이며 실제 3GPP topology나 message sequence가 아니다.

• 1. 단말·클라이언트정책 version, PDU Session, app transaction과 endpoint 관측을 함께 남긴다.
• 2. RANradio delay·loss·throughput, coverage, admission, mobility와 congestion을 수집한다.
• 3. 전송망segment delay·packet delay variation·loss, queue·link 이용률과 실제 경로를 수집한다.
• 4. 5G CoreN3·UPF 성능, session·policy 상태, NF capacity와 fault를 slice 식별자에 연결한다.
• 5. 애플리케이션 서비스server queue·compute·transaction latency·error·availability를 계약 endpoint에서 측정한다.
• 6. Telemetry 정합공통 시간축, topology, S-NSSAI·DNN·5QI·session·service 식별자를 맞추고 누락과 품질을 검사한다.
• 7. 구간 비교목표 위반을 탐지하고 여러 구간의 증거를 비교해 문제 범위를 좁힌다.
• 8. 책임 구간 확인망·전송·애플리케이션 가운데 조치가 필요한 경계와 담당 주체를 정한다.
• 9. 재검증같은 KPI·KQI endpoint에서 결과를 다시 측정한다.

3GPP TS 28.535·28.536은 monitoring, analysis, decision, execution과 AssuranceGoal 관리 수단을 정의한다. 이 글에서 중요한 것은 자동 실행의 상세가 아니라 측정 endpoint를 유지하는 일이다. RAN·transport·Core·application의 timestamp, 식별자와 집계 기준이 맞아야 KPI와 KQI를 같은 사건으로 비교할 수 있고, 조치 뒤에도 같은 경계에서 결과를 재측정해야 한다. AI 지원 범위와 통제권은 8편, policy execution·rollback과 incident 복구는 9편에서 다룬다.

종단간 보장이 깨지는 대표 상황

Roaming, multi-vendor, transport 우회, 단말·application version과 overload 상황에서는 측정 endpoint와 책임 경계가 바뀔 수 있다. 정상 경로의 KPI가 좋아도 우회 경로나 외부 server의 KQI가 나쁘면 종단간 목표를 증명할 수 없다. 따라서 같은 서비스 식별자·시간축·endpoint로 정상·혼잡·우회 조건을 비교해야 한다.

Fallback은 연결 연속성을 높일 수 있지만 원래 latency·isolation·security 목표를 낮출 수 있다. 여기서는 실패 유형을 열거하는 데 그치고, policy 충돌·변경 중지·rollback·고객 통지 같은 incident 확대와 복구 구조는 9편에서 다룬다.

다섯 종류의 문장을 섞지 않는 법

표준 사실은 규격이 정의한 대상과 동작 범위를 주어와 함께 쓴다. 예를 들면 “TS 28.554의 평균 slice 지연 KPI는 UE와 PSA UPF 사이를 측정한다”는 문장이다. 여기에는 사업자가 실제로 그 KPI를 수집한다거나 목표값을 달성한다는 의미를 더하지 않는다.

배포 선택은 행위 주체와 선택 조건을 밝힌다. “사업자는 transport queue와 UPF capacity를 예약하고 장애 경로에서 다시 시험할 수 있다”처럼 쓴다. 표준이 허용하거나 지원하는 기능과 현재 어느 사업자가 실제 적용했다는 사실을 구분한다.

상용 SLA는 계약된 endpoint, 목표값, 통계, 시간창, 제외 조건, 책임, 복구와 보상 규칙이 확인될 때만 주장한다. 공식 계약 근거 없이 “Network Slice는 10ms를 보장한다”거나 “99.999% availability를 제공한다”고 쓰지 않는다. 표준 KPI 정의는 계약서가 아니다.

필자 분석은 근거에서 도출한 판단임을 드러낸다. 필자는 종단간 보장의 핵심 경쟁력이 전용 자원 보유 자체보다 여러 도메인의 관측·조정·검증을 반복하는 운영 능력에 있다고 본다. 이는 표준 문구가 아니라 앞서 확인한 관리 구조와 실패 경계를 바탕으로 한 분석이다.

향후 가능성은 조건부 표현을 쓴다. 공통 telemetry와 안전한 automation이 성숙하면 slice assurance를 더 빠르게 반복하고, 계약 경계에 가까운 KQI 중심 제어를 넓힐 수 있다. 다만 현재 모든 vendor·roaming partner·OTT endpoint를 한 loop로 제어할 수 있다는 뜻은 아니다.

이 문장 구분은 기술 글의 겸손을 위한 장식이 아니다. 표준 준수, 제품 기능, 사업자 배포, 고객 계약, 전망을 한 문장에 섞으면 독자는 무엇이 이미 검증됐고 무엇이 조건부인지 알 수 없다. 특히 수익화, 가격, 소비자·기업 상품 설계, 망중립성, 정부 책임은 별도의 근거와 논의가 필요하다.

보장의 상한은 가장 약한 경계에서 결정된다

Network Slicing은 Network Slice와 Subnet의 lifecycle, profile, KPI, fault와 assurance goal을 관리할 수 있는 강한 틀을 제공한다. RAN과 Core만 보던 운영을 transport와 application/service 요구까지 연결하고, 여러 수준의 performance를 slice 식별자에 맞춰 관측할 수 있게 한다. 그러나 표준은 사업자의 spectrum, fiber, compute, server와 사람·조직의 실행력을 대신하지 않는다.

종단간 보장을 말하려면 먼저 종단을 정의해야 한다. UE↔PSA UPF인지, UE 앱↔managed edge인지, 고객 장비↔기업 application인지에 따라 측정과 책임이 달라진다. 그다음 각 구간의 latency, variation, loss, throughput, availability, reliability를 공통 시간축으로 연결하고, 목표 위반 시 어떤 조치를 누가 실행하는지 정해야 한다. 마지막으로 정상 경로뿐 아니라 overload, failure, roaming, fallback에서도 같은 기준을 시험해야 한다.

결론은 단순하다. slice를 선택했다는 사실, isolation profile이 있다는 사실, admission을 통과했다는 사실, capacity를 예약했다는 사실 가운데 어느 하나도 종단간 SLA를 홀로 증명하지 못한다. 보장은 여러 조건이 동시에 맞는 동안만 유지되며, assurance loop가 그 조건을 계속 확인하고 회복할 수 있어야 한다. 가장 약한 구간과 가장 불명확한 책임 경계가 실제 보장의 상한을 정한다.

공식 자료

• 3GPP TS 28.530 — Management and orchestration; Concepts, use cases and requirements
• 3GPP TS 28.531 — Provisioning
• 3GPP TS 28.541 — 5G Network Resource Model
• 3GPP TS 28.535 — Management services for communication service assurance
• 3GPP TS 28.536 — Management services for Network Slice assurance
• 3GPP TS 28.552 — 5G performance measurements
• 3GPP TS 28.554 — 5G end-to-end KPI
• 3GPP TS 23.501 — 5GS architecture and Network Slice Admission Control
• 3GPP — 5G Network slice management
• GSMA NG.116 V10.0 — Generic Network Slice Template
• ITU-T Y.1540 — Internet protocol data communication service performance parameters

이미지 설명: 여섯 개의 추상 영역을 통과하는 하나의 서비스 경로와, 마지막 관측 지점에서 앞 구간으로 돌아오는 feedback loop를 표현한 독창적 개념 이미지다. 실제 3GPP topology, message sequence, 표준 interface 또는 물리 자원 배치를 나타내지 않는다.