3GPP에서 Key Issue 기반으로 Solution을 분석하는 방법 (TDoc, Penholder 확인하기)

6G 아키텍처 논의를 따라가다 보면 TR 문서에는 Key Issue만 정의되어 있고, 실제 solution은 보이지 않는 경우가 많다.

이때 각 회사들이 초기 단계에서 논의하고 있는 사항은 TDoc(기여문)에 있다.

이를 체계적으로 분석하는 방법은 다음과 같다.

 

 

TR이 아니라 TDoc을 봐야 하는 이유

---

6G 아키텍처를 분석할 때 가장 먼저 접하는 문서는 TR(Technical Report)이다.

TR에서는 Key Issue를 기준으로 문제를 명확히 정의한다.

예를 들어 KI#2(SBA Framework)를 보면, 핵심은 NF discovery 최적화, load balancing 개선, 그리고 서비스의 resiliency 향상과 같은 문제들이다.

 

하지만 TR 문서는 Key Issue 중심으로 문제를 정의하고 방향성을 제시하는 역할을 하며, 대부분의 solution은 FFS(For Further Study) 상태로 남아 있기 때문에 TR만으로는 실제 기술 방향을 이해하기 어렵다.

 

이때 TR-23.801-01의 실제 solution은 TR이 아니라 3GPP의 meeting_3gpp_sync / SA2 / Inbox 폴더에 존재한다.

이곳은 SA2 회의 전에 각 회사가 제출한 TDoc(기여문)이 모여 있는 저장소로,

아직 합의되지 않은 상태의 원본 아이디어들이 그대로 담겨 있다.

 

 

즉, 해당 폴더는 TR이 문제 정의 문서라면 TDoc은 각 회사가 제안하는 “해결 방법”이자, 표준화 이전 단계의 생생한 기술 방향이 담겨있는 자료다.

 

• TR → 문제 정의 (Key Issue 중심)
• TDoc → 회사별 solution 제안
• Inbox → 실제 기술 방향이 모이는 공간

 

 

 

각 회사의 입장을 읽는 방법: TDoc과 Solution 리스트 활용하기

---

 

폴더 내부 구조를 보면 그 역할이 더 명확해진다.

Drafts에는 penholder가 여러 제안을 정리한 중간 문서가 있고,

Chair_Notes에는 회의 결과 요약이 담겨 있으며,

TEI20_...와 같은 폴더는 특정 작업 항목별 논의를 모아둔 공간이다.

 

 

 

 

그리고 실제로 중요한 것은 S2-260xxxx와 같은 파일들이다.

이 각각의 파일이 바로 하나의 TDoc이며, 특정 회사 또는 공동으로 제출된 기술 제안을 의미한다.

 

 

 

 

Chair Notes를 통한 penholder 식별

---

수십 개의 TDoc 중에서 어떤 문서를 봐야 하는가이다.

모든 TDoc을 다 보는 것은 비효율적이며, 실제 표준화 방향을 이해하는 데에도 적절하지 않다.

이때 활용해야 하는 것이 바로 Chair Notes다.

 

Chair Notes는 SA2 회의가 끝난 뒤, 회의에서 논의된 결과를 정리한 문서다.

여기에는 각 TDoc이 어떤 상태로 처리되었는지가 기록되어 있다.

예를 들어 어떤 문서는 단순 논의로 끝나고, 어떤 문서는 reject되며, 또 어떤 문서는 향후 논의의 기준으로 채택된다.

 

 

2/13일에 열린 Meeting의 결과 요약본을 위 파일에서 확인할 수 있다.

 

해당 파일에서 penholder를 검색하면 KI#2 SBA Framework에 대한 Penholder 파일이 무엇인지를 확인할 수 있다.

 

KI#2 SBA Framework에 대한 KI#2 SBA framework – penholders input 문서는 아래와 같다.

• S2-2601148
• S2-2601602
• S2-2601623

이 중 최신 정리본이 S2-2601623인 것!

 

 

 

KI#2 SBA framework에 대한 penholder 자료 확인하기

---

 

예를 들어 S2-2601623은 2026년 SA2에서 제출된 하나의 문서로, KI#2(SBA)에 대한 특정 solution을 담고 있다.

 

하지만 TDoc을 하나씩 보는 것만으로는 전체 흐름을 이해하기 어렵다.

이때 중요한 역할을 하는 것이 바로 “solution 리스트”다.

 

 

S2-2601623에서 확인할 수 있는 위의 표는 특정 회의(예: SA2#173)에서 KI#2와 관련해 어떤 회사가 어떤 문서를 제출했는지를 정리한 인덱스다. 즉, 단순한 목록이 아니라 전체 논의 구조를 한눈에 보여주는 지도라고 볼 수 있다.

 

이 표를 활용하면 분석 방식이 훨씬 명확해진다.

먼저 Subject 항목을 통해 각 문서의 핵심 방향을 빠르게 파악할 수 있다.

 

예를 들어 NF discovery 개선, load balancing 향상, SBA 구조 변경, roaming 단순화 등 다양한 접근 방식이 존재함을 확인할 수 있다.

 

이를 기반으로 유사한 solution끼리 그룹화하면, 개별 회사가 아니라 “solution 유형” 중심으로 전체 논의를 바라볼 수 있게 된다.

그리고 각 그룹에서 대표적인 TDoc 몇 개만 선택해 깊게 분석하면, 전체 흐름을 효율적으로 이해할 수 있다.

 

정리하면, 각 회사의 입장을 분석하는 과정은 다음과 같이 구성된다.

• TR에서 Key Issue 정의 파악
• Inbox에서 TDoc 확보
• Solution 리스트로 전체 구조 파악
• 유사한 solution을 그룹화
• 대표 문서를 중심으로 심층 분석

결국 중요한 것은 “누가 무엇을 냈는가”가 아니라,

"어떤 solution들이 존재하고, 어떤 방향으로 수렴되고 있는가”를 읽는 것!