5G NR Fundamental Part 12: RRC State Transition, RRC Inactive, Paging과 RRC Resume
| 이전 흐름 복습 Part 10에서는 Measurement Report와 Handover를 봤고, Part 11에서는 무선 링크가 무너졌을 때의 RLM, RLF, RRC Re-establishment를 정리했다. 이번 Part 12는 조금 다른 관점이다. 무선 품질이 나빠져서 복구하는 이야기가 아니라, 네트워크가 UE의 배터리와 시그널링 부하를 줄이기 위해 연결 상태를 어떻게 내려놓고, 필요할 때 다시 깨우는지를 다룬다. |
5G NR의 RRC_CONNECTED, RRC_INACTIVE, RRC_IDLE 상태 차이와 RRC Release, suspendConfig, RAN Paging, CN Paging, RRC Resume 절차를 실무 로그 분석 관점에서 설명합니다.
5G NR 로그를 보다 보면 처음에는 Handover나 RACH 같은 눈에 잘 보이는 절차에 관심이 간다.
그런데 실제 단말 동작을 오래 보면, 생각보다 많은 시간이 “연결되어 있는 듯하지만 완전히 연결된 것도 아닌 상태”에서 지나간다. 화면은 꺼져 있고 데이터는 거의 없지만, 카카오톡 알림이나 푸시 메시지는 바로 와야 한다.
반대로 네트워크 입장에서는 수많은 UE를 항상 RRC_CONNECTED로 붙잡고 있을 수 없다.
이 균형을 맞추기 위해 NR에서는 RRC_INACTIVE 상태가 중요해졌다. LTE의 관점으로만 보면 Idle과 Connected 사이가 조금 낯설 수 있다.
하지만 5G에서는 이 중간 상태를 이해해야 Paging, Resume, 지연시간, 배터리, 그리고 로그에서 보이는 갑작스러운 RACH까지 자연스럽게 이어진다.
1. RRC 상태 전환이 필요한 이유
RRC 상태는 단순히 “연결됨”과 “끊김”을 나누는 표시가 아니다.
실제로는 UE가 어떤 수준의 네트워크 문맥을 유지하고 있는지, 어떤 채널을 감시해야 하는지, 이동성은 누가 관리하는지, 데이터가 생겼을 때 얼마나 빨리 올라올 수 있는지를 결정한다.
예를 들어 사용자가 지하철에서 휴대폰 화면을 꺼둔 상태라고 해보자.
백그라운드 데이터는 가끔 있고, 대부분의 시간에는 아무 패킷도 없다.
이 UE를 계속 RRC_CONNECTED로 유지하면 gNB는 UE별 자원, 측정, 스케줄링 가능성을 계속 관리해야 한다. 수십 대라면 괜찮지만, 셀 안에 수천 대의 UE가 있다면 이야기가 달라진다.
반대로 UE를 바로 RRC_IDLE로 보내면 네트워크 부담은 줄어든다. 하지만 다시 데이터가 생길 때 NAS, RRC, 보안, 베어러 복구에 필요한 절차가 길어질 수 있다.
그래서 5G NR은 중간 지점으로 RRC_INACTIVE를 둔다.
이 상태에서는 UE와 NG-RAN이 일부 AS Context를 보관하고, 필요할 때 RRC Resume으로 빠르게 복귀할 수 있다.
| 핵심만 말하면, RRC 상태 전환은 “무선 자원 절약”, “UE 배터리 절약”, “빠른 서비스 복귀” 사이의 타협점이다. RRC Inactive는 이 타협을 5G답게 다루기 위해 들어온 상태라고 보면 이해가 쉽다. |
2. RRC_CONNECTED, RRC_INACTIVE, RRC_IDLE 차이
세 상태를 구분할 때는 “UE가 데이터를 바로 받을 수 있는가?”만 보면 부족하다.
실제 로그 분석에서는 Context가 어디까지 살아 있는지, 이동성 제어 주체가 누구인지, Paging이 CN에서 오는지 RAN에서 오는지까지 같이 봐야 한다.
| 구분 | RRC_CONNECTED | RRC_INACTIVE | RRC_IDLE |
| 체감 상태 | 데이터 송수신 준비 상태 | 잠시 쉬는 상태지만 빠른 복귀 가능 | 연결을 내려놓은 대기 상태 |
| UE Context | gNB와 UE가 활성 문맥 유지 | UE와 NG-RAN에 AS Context 보관 | RRC AS Context는 사실상 해제 |
| 이동성 | Measurement Report와 Handover 중심 | UE Cell Reselection + RNA 관리 | UE Cell Reselection + Tracking Area 관리 |
| Paging | 일반적으로 별도 Paging 없이 스케줄링 | RAN Paging 가능 | CN Paging 중심 |
| 복귀 절차 | 이미 연결됨 | RRC Resume | RRC Setup 또는 Registration/Service Request 흐름 |
| 로그에서 자주 보이는 메시지 | RRCReconfiguration, MeasurementReport | RRCRelease(suspendConfig), RRCResumeRequest, RRCResume, RRCResumeComplete | RRCSetupRequest, RRCSetup, RRCSetupComplete, Paging |
실무적으로는 RRC_INACTIVE를 “Idle보다 빠른 대기 상태”라고 표현하면 편하다.
다만 완전히 Idle과 같다고 보면 안 된다. UE는 Inactive 상태에서도 cell reselection을 수행하고, 설정된 RAN Notification Area를 벗어나는 경우에는 네트워크에 위치 갱신 성격의 절차를 수행해야 한다.
3. RRC Release와 suspendConfig
UE가 RRC_CONNECTED에서 내려갈 때 항상 Idle로 가는 것은 아니다.
네트워크는 RRCRelease 메시지에 suspendConfig를 포함해 UE를 RRC_INACTIVE로 보낼 수 있다.
이때 UE는 나중에 Resume에 사용할 식별자와 관련 설정을 받는다.
| 로그에서 중요한 포인트 RRCRelease가 보였다고 해서 무조건 Idle로 내려갔다고 판단하면 안 된다. 메시지 내부에 suspendConfig, fullI-RNTI 또는 shortI-RNTI, ran-NotificationAreaInfo 같은 정보가 있는지 확인해야 한다. |
이 차이는 로그 분석에서 꽤 중요하다.
어떤 장비 로그에서는 상위 이벤트 이름이 단순히 “RRC Release”로 찍히기 때문에, 실제로는 Inactive로 suspend된 UE를 Idle로 오해하는 경우가 있다.
이후 UE가 RRCResumeRequest를 보내면 “왜 Setup이 아니라 Resume이지?”라는 질문이 생기는데, 답은 앞에서 받은 suspendConfig에 있다.
Connected 상태에서 데이터가 한동안 없음
↓
gNB가 UE를 계속 붙잡아둘 필요가 낮다고 판단
↓
RRCRelease 메시지 전송
├─ suspendConfig 있음 → RRC_INACTIVE
└─ suspendConfig 없음 → RRC_IDLE 방향으로 이해4. Paging: CN Paging과 RAN Paging
Paging은 네트워크가 UE를 깨우는 절차다.
하지만 어떤 상태의 UE를 깨우느냐에 따라 의미가 조금 달라진다.
Idle 상태 UE는 코어망 관점의 위치 관리, 즉 Tracking Area 기반으로 찾는 흐름이 중심이다.
반면 Inactive 상태 UE는 NG-RAN이 UE Context를 알고 있으므로 RAN 기반으로 Paging할 수 있다.
| 구분 | CN Paging | RAN Paging |
| 주 대상 | RRC_IDLE UE | RRC_INACTIVE UE |
| 주도 주체 | AMF 등 코어망 | NG-RAN, 보통 마지막 Serving gNB 또는 Context Anchor 역할의 노드 |
| 위치 관리 단위 | Tracking Area | RAN Notification Area, RNA |
| UE 복귀 흐름 | RRC Setup, NAS Service Request 등으로 이어질 수 있음 | RRC Resume 중심 |
| 장점 | 넓은 영역에서 UE 탐색 가능 | 기존 AS Context 재사용으로 빠른 복귀 가능 |
여기서 헷갈리기 쉬운 부분은 “Paging을 받으면 무조건 RRC Setup을 한다”는 생각이다.
Inactive UE라면 Paging 이후에 Setup이 아니라 Resume으로 올라올 수 있다.
반대로 UE가 이미 Context를 잃었거나 네트워크가 UE Context를 더 이상 사용할 수 없다면 Resume이 실패하고 Setup 계열 절차로 돌아갈 수 있다.
5. RRC Resume 절차
RRC Resume은 Inactive 상태 UE가 다시 Connected로 올라오는 절차다. 원인은 크게 두 가지로 볼 수 있다.
하나는 네트워크가 Paging으로 UE를 깨운 경우이고, 다른 하나는 UE 쪽에서 uplink data가 생긴 경우다.
로그 관점에서 가장 단순한 흐름은 다음과 같다.
UE in RRC_INACTIVE
↓
Paging 수신 또는 UL 데이터 발생
↓
Random Access 수행
↓
RRCResumeRequest 전송
↓
gNB가 UE Context 확인
↓
RRCResume 전송
↓
RRCResumeComplete 전송
↓
RRC_CONNECTED 복귀
여기서 중요한 점은 Resume이 “새로 연결을 만드는 절차”라기보다는 “기존 문맥을 되살리는 절차”에 가깝다는 것이다.
그래서 메시지 이름도 Setup이 아니라 Resume이다. UE는 Inactive로 내려갈 때 받은 식별자와 보관 중인 AS Context를 활용하고, 네트워크는 해당 UE Context를 찾아 보안과 무선 베어러를 다시 사용할 수 있는 상태로 만든다.
RRCResumeRequest에서 보는 값
로그에서 RRCResumeRequest를 보면 먼저 resume cause를 확인하는 습관이 좋다.
원인이 mobile originated data인지, mobile terminated access인지, emergency인지에 따라 앞뒤 흐름이 달라진다.
특히 앱에서 작은 uplink 패킷 하나가 발생했을 뿐인데 RACH와 Resume이 이어지는 로그는 처음 보면 꽤 시끄럽게 느껴진다.
| 확인 | 항목의미 | 로그 해석 팁 |
| I-RNTI 계열 식별자 | Inactive UE Context를 찾는 단서 | 이전 RRCRelease의 suspendConfig와 연결해서 본다. |
| Resume Cause | Resume을 시작한 이유 | UL 데이터 발생인지, Paging 반응인지 구분한다. |
| Selected Cell | UE가 Resume을 시도한 셀 | Inactive 중 cell reselection이 있었는지 판단한다. |
| Security/Integrity 결과 | 기존 보안 문맥을 신뢰할 수 있는지 | 실패 시 fallback 또는 재연결 흐름으로 이어질 수 있다. |
6. RNA와 RNA Update
RRC Inactive를 이해할 때 RNA, RAN Notification Area를 빼놓으면 안 된다.
Idle 상태에서는 Tracking Area가 위치 관리 단위로 중요하지만, Inactive 상태에서는 RAN 쪽에서 UE를 찾을 수 있는 영역이 필요하다.
이 역할을 하는 것이 RNA다.
UE가 Inactive 상태에서 이동하다가 설정된 RNA를 벗어나면 네트워크는 더 이상 “이 UE가 이 RAN 영역 안에 있겠지”라고 확신하기 어렵다.
그래서 UE는 RNA Update를 수행한다.
로그에서는 짧은 Resume처럼 보이거나, 위치 갱신 성격의 RRC 메시지 흐름으로 보일 수 있다.
| 현장에서 자주 생기는 오해 Inactive 상태 UE가 움직인다고 해서 매번 Handover가 발생하는 것은 아니다. Handover는 Connected 상태에서 네트워크가 제어하는 이동성에 가깝고, Inactive/Idle에서는 UE가 cell reselection을 수행한다. 따라서 이동 중 로그에서 Handover가 보이지 않는다고 해서 이상한 것은 아니다. |
| 이동성 항목 | Connected | Inactive | Idle |
| 기본 이동 방식 | Network controlled mobility | UE controlled cell reselection | UE controlled cell reselection |
| 영역 관리 | Serving Cell / Neighbor Cell 측정 기반 | RNA 기반 | Tracking Area 기반 |
| 주요 이벤트 | Measurement Report, Handover | RNA Update, RAN Paging | TAU/Registration 관련 절차, CN Paging |
7. RRC Resume에서 Random Access가 보이는 이유
Resume은 RRC 절차인데 왜 MAC Random Access가 먼저 보일까?
이유는 단순하다.
UE가 Inactive 상태에서는 gNB와 지속적인 uplink timing, 스케줄링 상태를 유지하지 않는다.
다시 메시지를 올리려면 먼저 uplink 동기를 맞추고, 초기 전송 기회를 확보해야 한다.
그래서 Resume 로그 앞에는 RACH가 붙는 경우가 많다. 이때 분석 순서는 보통 다음처럼 잡으면 편하다.
- UE가 어떤 셀을 선택했는지 확인한다.
- RACH preamble 전송과 Random Access Response가 정상인지 본다.
- Contention resolution 또는 2-step RA 결과를 확인한다.
- 이후 RRCResumeRequest가 올라갔는지 본다.
- gNB가 RRCResume을 내려줬는지, 아니면 Release/Reject 계열로 정리했는지 본다.
무선 품질이 애매한 환경에서는 Resume 실패가 RRC 문제처럼 보이지만 실제 시작점은 RACH 실패인 경우가 적지 않다.
특히 지하 주차장, 엘리베이터, 셀 경계처럼 RSRP는 보이지만 uplink가 불안한 구간에서는 이 부분을 먼저 확인하는 것이 좋다.
8. Resume 실패와 재시도 흐름
RRC Resume이 항상 성공하는 것은 아니다.
UE가 Inactive로 내려간 뒤 너무 오래 지나 Context가 사라졌거나, UE가 다른 gNB 영역으로 이동했는데 Context retrieval이 매끄럽지 않거나, 보안 검증에 실패하거나, 단순히 RACH 단계에서 막히는 경우도 있다.
| 실패 유형 | 가능한 원인 | 확인 포인트 |
| RACH 실패 | UL 커버리지 부족, preamble collision, power ramping 한계 | RA attempt 수, RAR 수신 여부, preamble power, 셀 품질 |
| Context not found | gNB가 UE Context를 찾지 못함 | I-RNTI, old gNB/target gNB 관계, Context 보관 시간 |
| Security 실패 | 보안 문맥 불일치 또는 무결성 검증 문제 | RRC Resume 이후 integrity failure, fallback 여부 |
| Cell reselection 이슈 | UE가 적절하지 않은 셀에서 Resume 시도 | 선택 셀의 SSB RSRP/RSRQ/SINR, barred/reserved 상태 |
| Network Reject/Release | 부하, 정책, Context 만료, 재설정 필요 | RRCReject, RRCRelease, waitTime, 이후 RRC Setup 여부 |
실패 후 UE는 상황에 따라 다시 Resume을 시도하거나, 아예 Idle 기반의 Setup 절차로 돌아갈 수 있다.
따라서 로그에서 “Resume이 한 번 실패했다”는 사실보다 더 중요한 것은 그 다음에 UE가 어떤 경로를 선택했는지다.
바로 Setup으로 전환되었다면 Context 재사용이 어려웠던 것으로 볼 수 있고, 동일 셀에서 RACH만 반복했다면 무선 접속 자체가 문제일 가능성이 커진다.
9. 로그 분석 시 확인 포인트
RRC Inactive와 Resume 로그는 메시지 수가 아주 많지는 않지만, 앞뒤 문맥을 놓치면 해석이 어려워진다.
특히 RRCRelease와 RRCResumeRequest 사이에 시간이 길게 비어 있는 경우가 많아, 한 화면에서 연속 절차처럼 보이지 않을 수 있다.
1) RRCRelease 내부를 먼저 본다
suspendConfig가 있는지, 어떤 I-RNTI가 내려갔는지, RNA 정보가 있는지 확인한다.
이 정보가 있어야 나중에 ResumeRequest와 연결할 수 있다.
2) Paging이 있었는지, UL Trigger였는지 구분한다
Resume 직전에 Paging 수신이 있었는지 확인한다.
Paging이 없다면 앱의 uplink data, NAS signaling, RNA Update 같은 UE-originated 원인을 의심한다.
3) RACH 결과를 먼저 배제한다
RRC Resume이 보이지 않는다고 바로 RRC 문제로 판단하지 않는다.
UE가 ResumeRequest를 보내기 전 RACH에서 막히면 RRC 메시지는 올라오지도 못한다.
4) Resume 이후 DRB와 보안 상태를 확인한다
RRCResume이 내려왔다고 끝이 아니다.
이후 RRCResumeComplete, 보안 관련 상태, DRB 재활성, 사용자 데이터가 실제로 흐르는지까지 봐야 한다.
5) Inactive 중 이동 여부를 본다
Resume을 시도한 셀이 suspend 시점의 셀과 다른지 확인한다.
다른 셀에서 Resume한다면 Context retrieval이나 RNA 설정이 분석 포인트가 된다.
| 실무식 한 줄 정리 Resume 문제는 “RRCResumeRequest가 있었는가?”만 보면 부족하다. RRCRelease(suspendConfig) → Inactive 체류 → Paging/UL Trigger → RACH → ResumeRequest → Context 확인 → ResumeComplete → 데이터 흐름까지 한 줄로 이어서 봐야 한다. |
10. 메시지 흐름 예시
아래는 특정 벤더 로그 형식이 아니라, 절차를 이해하기 위한 학습용 예시다.
[Connected → Inactive]
UE gNB
| |
| 데이터 inactivity |
| |
| <---- RRCRelease --------| suspendConfig 포함
| |
| RRC_INACTIVE 진입 |
| |
[Inactive → Connected Resume]
UE gNB
| |
| <---- Paging -----------| 또는 UE UL Data 발생
| |
| ---- Random Access ---->|
| ---- RRCResumeRequest ->|
| <---- RRCResume --------|
| ---- RRCResumeComplete >|
| |
| RRC_CONNECTED 복귀 |11. Part 10, Part 11과 연결해서 보기
Part 10의 Handover는 Connected 상태에서 네트워크가 UE의 이동성을 관리하는 절차였다.
Part 11의 RLF와 Re-establishment는 Connected 상태에서 링크가 깨졌을 때 복구하는 흐름이었다.
이번 Part 12의 Inactive와 Resume은 “문제가 생겨서 복구”라기보다는, 네트워크가 의도적으로 연결을 가볍게 내려놓았다가 다시 끌어올리는 흐름에 가깝다.
| 파트 | 핵심 상황 | 주요 메시지 / 절차 | 분석 관점 |
| Part 10 | Connected 상태에서 셀 이동 | Measurement Report, RRCReconfiguration, Handover | 어느 셀이 더 좋은가, 언제 넘길 것인가 |
| Part 11 | 무선 링크 악화 및 복구 | RLM, RLF, RRCReestablishment | 링크가 왜 끊겼고 복구가 가능한가 |
| Part 12 | 연결 절약과 빠른 복귀 | RRCRelease, Paging, RRCResume | Context를 유지한 채 얼마나 빨리 복귀하는가 |
12. FAQ
Q1. RRC Inactive는 Idle과 같은 건가요?
아니다.
둘 다 UE가 계속 Connected로 스케줄링되는 상태는 아니지만, Inactive는 UE와 NG-RAN이 AS Context를 보관하고 Resume으로 빠르게 복귀할 수 있다는 점이 다르다.
Idle은 더 가볍지만 다시 올라올 때 절차가 길어질 수 있다.
Q2. RRCRelease가 보이면 항상 Idle로 간 건가요?
아니다.
RRCRelease 안에 suspendConfig가 포함되어 있으면 UE는 RRC Inactive로 들어갈 수 있다.
로그 분석 시 Release 메시지 이름만 보지 말고 내부 IE를 확인해야 한다.
Q3. Inactive 상태에서 이동하면 Handover가 발생하나요?
일반적으로 Connected 상태의 이동성은 Handover로 관리되고, Inactive 상태에서는 UE가 cell reselection을 수행한다.
따라서 Inactive 중 이동했다고 해서 Handover 메시지가 반드시 보이는 것은 아니다.
Q4. Paging 이후 왜 RACH가 보이나요?
UE가 Inactive나 Idle 상태에서는 uplink 전송을 위한 동기와 스케줄링 상태를 계속 유지하지 않는다.
다시 RRC 메시지를 올리기 위해 Random Access가 먼저 필요할 수 있다.
Q5. RRC Resume이 실패하면 무조건 네트워크 문제인가요?
그렇지 않다.
RACH 실패, 무선 품질 문제, Context 만료, 다른 셀에서의 Context retrieval 실패, 보안 문맥 불일치 등 원인이 다양하다. ResumeRequest 전후만 보지 말고 RRCRelease 시점과 RACH 단계까지 함께 확인해야 한다.
Q6. RAN Paging과 CN Paging은 로그에서 어떻게 구분하나요?
UE 상태와 앞선 Release 형태를 함께 본다.
Inactive로 suspend된 UE가 RNA 안에서 깨워지는 흐름이라면 RAN Paging 관점으로 볼 수 있고, Idle UE를 코어망이 Tracking Area 기반으로 찾는 흐름이라면 CN Paging 관점이 강하다.
13. 3GPP 공식 참고자료
- 3GPP TS 38.331 - NR; Radio Resource Control (RRC); Protocol specification
RRCRelease, RRCResumeRequest, RRCResume, RRCResumeComplete 등 RRC 메시지와 IE 확인에 필요하다.
https://www.3gpp.org/dynareport/38331.htm
- 3GPP TS 38.300 - NR; NR and NG-RAN Overall description; Stage-2
NG-RAN 관점의 RRC 상태, RRC Inactive, Paging, Resume 개념을 큰 구조로 이해할 때 유용하다.
https://www.3gpp.org/dynareport/38300.htm
- 3GPP TS 38.304 - NR; User Equipment (UE) procedures in Idle mode and in RRC Inactive state
Idle/Inactive 상태의 UE 절차, cell reselection, RNA 관련 개념을 확인할 때 필요하다.
https://www.3gpp.org/dynareport/38304.htm
- 3GPP TS 38.321 - NR; Medium Access Control (MAC) protocol specification
Resume 이전 Random Access 동작을 MAC 관점에서 확인할 때 참고한다.
https://www.3gpp.org/dynareport/38321.htm
마무리
RRC Inactive는 처음에는 “Idle과 Connected 사이 어딘가” 정도로만 보이지만, 실제 5G NR 로그에서는 배터리 절약, 지연시간, Paging, Resume, RNA Update가 모두 이 상태와 연결된다. 특히 Part 10의 Handover, Part 11의 RLF와 함께 보면 차이가 더 선명해진다.
Connected 상태에서는 네트워크가 UE를 붙잡고 세밀하게 제어한다. Inactive 상태에서는 UE가 잠시 물러나 있지만 Context를 버리지는 않는다. Idle 상태에서는 더 가볍게 대기하지만 복귀 절차가 상대적으로 길어진다. 이 세 상태의 차이를 이해하면, “왜 갑자기 RACH가 떴는지”, “왜 Setup이 아니라 Resume인지”, “왜 Handover 없이 셀이 바뀌었는지” 같은 로그의 의문이 훨씬 잘 풀린다.
'Wireless > Protocol' 카테고리의 다른 글
| [Protocol] 5G NR Fundamental - Part 14 (1) | 2026.05.27 |
|---|---|
| [Protocol] 5G NR Fundamental - Part 13 (0) | 2026.05.26 |
| [Protocol] 5G NR Fundamental - Part 11 (0) | 2026.05.24 |
| [Protocol] 5G NR Fundamental - Part 10 (0) | 2026.05.21 |
| [Protocol] 5G NR Fundamental - Part 9 (0) | 2026.05.20 |