완전히 연결된 UE와 완전히 유휴 상태인 UE 사이에 5G는 사용자 입장에서는 조용해 보이지만 NG-RAN 내부에서는 기술적으로 중요한 상태를 도입했습니다. 이 상태가 바로 RRC Inactive입니다. 이 상태는 5G 연결 관리의 현실적인 문제를 해결하기 위해 추가되었습니다. 많은 장치는 데이터 전송으로 빠르게 복귀해야 하지만 모든 장치를 항상 RRC Connected 상태로 유지하면 시그널링 자원, 무선 자원, 배터리 전력이 낭비되기 때문입니다.
스마트폰은 백그라운드 메시지를 확인할 수 있고, 센서는 짧은 데이터 버스트를 전송할 수 있으며, 애플리케이션은 오랜 무통신 기간 뒤 잠깐 깨어날 수 있습니다. 이러한 트래픽 패턴은 항상 완전한 유휴 상태로 돌아간 뒤 전체 연결 설정 절차를 다시 수행할 필요가 없습니다. RRC Inactive는 중간 계층을 제공합니다. UE는 활동을 줄이고 핵심 컨텍스트를 유지하며 상향 또는 하향 데이터가 발생할 때 더 빠르게 연결을 재개할 수 있습니다.
중요한 점은 RRC Inactive가 RRC Idle과 같지 않다는 것입니다. RRC Idle에서는 코어 네트워크 관점에서도 UE가 CM-IDLE 상태입니다. 반면 RRC Inactive에서는 UE가 CM-CONNECTED 상태를 유지하지만 RRC 계층의 활성 연결 동작만 일시 중단됩니다. gNodeB는 UE 컨텍스트를 보존하고 UE는 AS 컨텍스트를 유지하므로 네트워크는 모든 절차를 처음부터 다시 시작하지 않고 재개 절차를 통해 UE를 RRC Connected로 돌려보낼 수 있습니다.
5G에 이 상태가 필요한 이유
5G 연결 관리는 동시에 다양한 트래픽 유형을 처리해야 합니다. 일부 서비스는 높은 처리량과 지속 연결이 필요하고, 일부는 짧고 간헐적인 데이터 교환만 필요합니다. 또 어떤 단말은 오랫동안 조용히 있다가 네트워크나 애플리케이션이 필요로 할 때 빠르게 응답해야 합니다. 모든 UE를 RRC Connected로 유지하면 네트워크에 불필요한 제어 오버헤드가 발생합니다. 반대로 모든 비활성 UE를 완전히 RRC Idle로 전환하면 연결 복구가 느려지고 시그널링 부담이 커질 수 있습니다.
RRC Inactive는 이 간극을 줄입니다. UE는 RRC Connected 의미의 활성 데이터 처리를 중지할 수 있지만 중요한 액세스 스트라텀 컨텍스트는 폐기되지 않습니다. 따라서 이후 재개 절차를 통해 더 빠르게 연결을 복구할 수 있습니다. 사용자 경험 측면에서는 장치가 빠르게 반응하는 것처럼 보이고, 네트워크 측면에서는 필요한 시간보다 오래 활성 자원을 유지하지 않아도 됩니다.
이 설계는 자주 깨어나지만 긴 세션을 유지하지 않는 애플리케이션에 특히 유용합니다. 메시징 서비스, 백그라운드 동기화, 간헐적 센서 보고, 소규모 상향 데이터 버스트, 짧은 하향 알림은 모두 연결 상태로 더 빠르게 돌아갈 수 있는 상태의 이점을 얻을 수 있습니다.
네트워크 아키텍처 관점에서도 RRC Inactive는 이동성과 페이징 책임의 일부를 NG-RAN으로 넘긴다는 점에서 유용합니다. AMF는 로컬 RAN 알림 영역 안에서의 모든 이동을 코어 네트워크 이동성 이벤트로 처리할 필요가 없습니다. gNodeB는 UE 컨텍스트와 로컬 페이징 동작을 더 효율적으로 관리할 수 있습니다.
이 상태의 정의
RRC Inactive에는 몇 가지 핵심 특성이 있습니다. 첫째, UE는 여전히 CM-CONNECTED 상태로 간주됩니다. 이는 UE가 CM-IDLE 상태이기도 한 RRC Idle과의 중요한 차이입니다. RRC 연결이 일반적인 연결 모드 데이터를 능동적으로 전달하지 않더라도 5G 코어와의 연결 관계는 유지됩니다.
둘째, 이 상태는 코어 네트워크에 대체로 투명합니다. 정상 동작에서 AMF는 NG-RAN처럼 RRC Inactive를 직접 관리할 필요가 없습니다. 마지막으로 UE를 서비스한 gNodeB가 UE 컨텍스트를 유지하고 UE가 속한 RAN Notification Area를 알고 있습니다. 이 컨텍스트 보존 덕분에 빠른 복구가 가능합니다.
셋째, UE와 gNodeB는 AS 계층 컨텍스트를 유지합니다. 액세스 스트라텀 컨텍스트가 보존되므로 서비스 재개 시 UE는 완전히 새로운 설정을 수행할 필요가 없습니다. 대신 RRC Resume 절차를 사용해 RRC Connected로 돌아갈 수 있습니다.
RRC Inactive로의 전환은 suspend 설정이 포함된 RRC Release 메시지를 통해 이루어집니다. 그래서 이 상태는 일반적으로 suspend 및 resume 절차와 함께 설명됩니다. 네트워크는 활성 RRC 연결을 해제하지만 컨텍스트를 완전히 버리게 하지 않고 UE에 일시 중단하도록 지시합니다.
다시 활동이 필요해지면 UE는 RRC Inactive에서 RRC Connected로 이동할 수 있습니다. 이는 UE에 전송할 상향 데이터가 있거나 하향 데이터를 위한 RAN 페이징을 수신할 때 발생할 수 있습니다. 비활성 상태가 너무 오래 지속되면 gNodeB의 UE Inactivity Timer가 결국 N2 해제를 유발해 UE를 RRC Idle 및 CM-IDLE 쪽으로 이동시킬 수 있습니다.
UE가 계속 수행할 수 있는 작업
RRC Inactive가 UE가 멈춘 상태를 의미하지는 않습니다. UE가 활성 RRC Connected 상태가 아니더라도 여러 절차를 계속 수행할 수 있습니다. UE는 PLMN 선택, 시스템 정보 방송 수신, 셀 재선택, RAN이 시작한 페이징 응답을 수행할 수 있습니다. 이러한 기능은 완전한 활성 RRC 연결을 유지하지 않고도 UE를 도달 가능한 상태로 유지하는 데 도움이 됩니다.
네트워크 측도 특정 방식으로 계속 동작합니다. NG-RAN은 RAN Notification Area를 관리하고 RAN 페이징용 DRX를 설정하며 UE의 AS 컨텍스트를 보존합니다. gNodeB는 UE가 어느 RNA에 속하는지 알고 있으므로 데이터나 시그널링 때문에 UE 재개가 필요할 때 로컬 페이징 범위를 결정할 수 있습니다.
또 하나 중요한 점은 이 동작 모델에서 UE의 N2 및 N3 연결 컨텍스트를 유지할 수 있다는 것입니다. 이는 하향 데이터가 도착할 때 중요합니다. UPF는 계속 gNodeB 주소를 알고 마지막으로 UE를 서비스한 gNodeB로 하향 데이터를 전달할 수 있습니다. 그러면 gNodeB는 코어 네트워크 페이징 절차를 처음부터 시작하는 대신 설정된 RNA 내부에서 페이징을 트리거합니다.
이러한 보존 요소는 RRC Inactive가 유용한 이유와 함께 단순한 유휴 동작보다 복잡한 이유를 보여 줍니다. 네트워크는 빠른 복구에 충분한 컨텍스트를 보존해야 하지만 상태가 RRC Connected와 동일해질 정도로 많은 활성 자원을 할당해서는 안 됩니다. 이 균형이 바로 이 상태의 가치입니다.
RNA가 이동성을 제어하는 방식
RNA는 RAN Notification Area를 의미합니다. RRC Inactive 상태의 UE에 사용되는 RAN 측 알림 영역입니다. RNA는 여러 셀로 구성되며 일반적으로 같은 Tracking Area 안에 있습니다. UE가 할당된 RNA 내부를 이동할 때 셀이 바뀔 때마다 네트워크에 알릴 필요가 없습니다. 따라서 UE가 로컬 영역 안에서만 이동할 때 불필요한 시그널링을 피할 수 있습니다.
RNA는 RNA ID로 식별됩니다. 이 식별자는 TAC와 RAN Area Code로 구성되며 RAN Area Code 범위는 0부터 255까지입니다. 실무적으로는 NG-RAN이 비활성 UE가 자주 업데이트하지 않고 이동할 수 있는 로컬 영역을 간결하게 정의할 수 있습니다.
마지막으로 UE를 서비스한 gNodeB는 RRC Release 메시지의 suspend 설정을 통해 RNA ID를 할당합니다. 마지막 gNodeB가 UE의 RNA 컨텍스트를 알고 있어야 하므로 이는 중요한 세부 사항입니다. 나중에 하향 데이터가 발생하면 해당 gNodeB는 적절한 영역 안에서 UE를 어떻게 페이징할지 결정할 수 있습니다.
특정 조건에서는 UE가 여전히 네트워크를 업데이트해야 합니다. 주기적 RNA 업데이트 타이머가 만료되거나 UE가 설정된 RNA를 벗어나면 RNA 업데이트 절차를 시작해야 합니다. 이를 통해 RNA 내부의 일반적인 이동에 과도한 시그널링을 발생시키지 않으면서도 NG-RAN이 UE의 로컬 영역 정보를 잃지 않도록 합니다.
RNA 설계는 페이징 효율에 영향을 줍니다. RNA가 너무 작으면 UE가 이동할 때 빈번한 업데이트가 발생할 수 있고, 너무 크면 하향 데이터 도착 시 더 많은 셀을 페이징해야 해 오버헤드가 증가할 수 있습니다. 따라서 적절한 계획은 사용자 이동 패턴, 셀 배치, gNodeB 경계, 예상 서비스 동작을 고려해야 합니다.
하향 데이터 전달 방식
하향 데이터 처리는 RRC Inactive가 존재하는 이유를 가장 분명하게 보여 주는 사례 중 하나입니다. UE가 RRC Inactive 상태일 때 UPF에서 하향 데이터가 도착하면 데이터는 마지막으로 UE를 서비스한 gNodeB로 전송될 수 있습니다. gNodeB는 UE가 비활성이지만 RAN 수준 페이징을 통해 로컬에서 도달 가능하다는 사실을 알고 있으므로 RNA 안에서 페이징을 시작합니다.
RNA의 모든 셀이 마지막 gNodeB에 속해 있다면 절차는 비교적 단순합니다. gNodeB가 관련 셀에서 UE를 페이징합니다. UE는 RAN 페이징 메시지를 수신하고 RRC Resume 절차를 시작해 RRC Connected로 돌아갑니다. 재개가 완료되면 UE는 하향 데이터를 받을 수 있습니다.
RNA에 인접 gNodeB가 서비스하는 셀이 포함되어 있다면 마지막 gNodeB는 Xn 시그널링을 사용할 수 있습니다. 인접 gNodeB에 XnAP RAN Paging 메시지를 전송하여 해당 셀에서도 페이징이 이루어지게 할 수 있습니다. 이 방식은 페이징 범위를 마지막 gNodeB 자체 셀에만 제한하지 않고 RNA 전체에 맞춥니다.
AMF에서 하향 UE 연관 시그널링이 도착할 때도 UE Context Release Command처럼 다른 처리 경로가 적용되는 경우를 제외하면 같은 기본 원리가 적용됩니다. 핵심은 NG-RAN이 비활성 UE의 페이징 절차를 관리할 수 있고, 이를 즉시 완전한 유휴 모드의 코어 네트워크 페이징 사례로 취급할 필요가 없다는 점입니다.
서비스 관점에서 사용자 경험은 UE가 얼마나 빨리 페이징을 수신하고 재개를 완료하는지에 달려 있습니다. 네트워크 관점에서는 컨텍스트를 재사용하고 시그널링을 로컬화함으로써 효율이 향상됩니다.
재개 전환의 동작 방식
RRC Inactive는 UE 측 또는 네트워크 측에서 RRC Connected로 돌아갈 수 있습니다. UE에 상향 데이터나 시그널링 요구가 있을 때 UE가 시작하는 전환이 발생합니다. UE는 gNodeB로 RRC Resume Request를 보냅니다. 현재 gNodeB가 마지막으로 UE를 서비스한 gNodeB가 아니라면 재개를 완료하기 전에 마지막 gNodeB에서 UE 컨텍스트를 가져와야 할 수 있습니다.
일반적인 UE 시작 절차에는 RRC Resume Request, Retrieve UE Context Request, Retrieve UE Context Response, RRC Resume, RRC Resume Complete가 포함될 수 있습니다. 서비스 gNodeB가 변경되면 Xn-U Address Indication, AMF를 향한 Path Switch Request 같은 추가 절차가 필요할 수 있습니다. 경로 전환이 처리된 뒤에는 적절한 시점에 이전 컨텍스트를 해제할 수 있습니다.
네트워크가 시작하는 전환은 다르게 시작됩니다. 마지막으로 UE를 서비스한 gNodeB가 하향 데이터나 관련 시그널링을 수신하고 RAN 페이징을 트리거합니다. UE는 RNA 안에서 페이징됩니다. 페이징을 수신한 UE는 RRC Inactive에서 재개하여 RRC Connected로 돌아가고 대기 중인 데이터나 시그널링을 처리합니다.
이러한 전환은 유휴 상태에서 전체 연결 설정을 수행하는 것보다 가볍게 설계되었습니다. 그렇다고 절차가 단순한 것은 아닙니다. 올바른 동작은 저장된 컨텍스트, gNodeB 간 조정, 필요한 경우 AMF 경로 전환, 새 서비스 경로가 구축된 뒤의 정확한 컨텍스트 해제에 달려 있습니다.
타이머 경로도 중요합니다. UE가 gNodeB의 UE Inactivity Timer 정책보다 오래 비활성 상태를 유지하면 네트워크는 UE를 RRC Idle로 이동시킬 수 있습니다. 일반적으로 N2 해제가 수반되고 코어 네트워크 상태가 CM-IDLE로 변경됩니다. 이 시점부터는 RRC Inactive의 빠른 재개 이점이 적용되지 않습니다.
AMF가 상태 보고를 받는 방식
RRC Inactive는 코어 네트워크에 투명하다고 설명되는 경우가 많지만 이 표현은 신중하게 해석해야 합니다. 일반적으로 AMF는 NG-RAN처럼 UE의 RRC 상태를 직접 제어하지 않습니다. 그러나 AMF는 NGAP 시그널링을 통해 RRC 상태 전환 보고를 요청할 수 있습니다.
AMF는 Initial Context Setup Request 또는 UE Context Modification Request 같은 메시지에 RRC Inactive Transition Report Request 매개변수를 포함할 수 있습니다. 요청이 후속 상태 전환 보고로 설정되면 gNodeB는 UE가 RRC Inactive로 진입하거나 이 상태에서 벗어날 때 보고해야 합니다.
상태 변화가 발생하면 gNodeB는 AMF로 RRC Inactive Transition Report를 전송합니다. 보고에는 Inactive 또는 Connected와 같은 RRC State 값이 포함됩니다. 이 메커니즘은 RRC Inactive 동작을 NG-RAN이 관리한다는 기본 사실을 바꾸지 않으면서 요청한 AMF에 상태 가시성을 제공합니다.
이 보고 기능은 네트워크 조정, 정책 인식, 운영 모니터링에 유용합니다. 또한 RRC Inactive를 코어 네트워크에 완전히 보이지 않는 상태라고 단순하게 설명해서는 안 되는 이유를 보여 줍니다. 더 정확히 말하면 주로 RAN이 관리하고, AMF는 지정된 조건에서 상태 전환 정보를 받을 수 있는 상태입니다.
엔지니어링 분석에서는 이 차이가 중요합니다. 절차가 실패하면 문제 해결 과정에서 RAN 동작과 NGAP 보고 동작을 모두 살펴봐야 할 수 있습니다. UE 상태, gNodeB 컨텍스트, RNA 설정, RAN 페이징, AMF 보고 요청, 경로 전환 처리가 모두 최종 결과에 영향을 줄 수 있습니다.
자주 묻는 질문
RRC Inactive가 RRC Idle과 같지 않은 이유는 무엇인가요?
RRC Inactive는 UE를 CM-Connected 상태로 유지하고 액세스 스트라텀 컨텍스트를 보존합니다. 반면 RRC Idle은 코어 네트워크와도 유휴 관계에 있으며 연결 복구에 더 무거운 절차가 필요합니다.
UE가 RRC Inactive에서 재개하도록 트리거하는 것은 무엇인가요?
재개는 UE의 상향 데이터, UE의 시그널링 요구, 또는 하향 데이터나 지원되는 하향 시그널링으로 인해 발생한 RAN 페이징에 의해 시작될 수 있습니다.
RNA가 시그널링을 줄이는 이유는 무엇인가요?
RNA는 UE가 정의된 RAN 알림 영역 안에서 이동할 때 셀 변경마다 네트워크에 알리지 않아도 되게 하므로 불필요한 로컬 이동성 시그널링을 줄입니다.
UE가 RNA를 벗어나면 어떻게 되나요?
UE는 RNA 업데이트 절차를 시작하여 NG-RAN이 로컬 페이징과 비활성 상태 도달성에 사용하는 영역 정보를 갱신할 수 있도록 해야 합니다.
인접 gNodeB가 페이징에 관여할 수 있는 이유는 무엇인가요?
RNA에 인접 gNodeB가 서비스하는 셀이 포함되면 마지막으로 UE를 서비스한 gNodeB가 XnAP RAN Paging을 보내 인접 셀에서도 UE를 페이징하게 할 수 있습니다.
AMF는 언제 RRC 상태 변화를 알게 되나요?
AMF가 지원되는 NGAP 절차에서 RRC Inactive Transition Report Request 매개변수를 사용해 요청한 경우 상태 전환 보고를 받을 수 있습니다.
RRC Inactive는 5G 연결 관리에서 가장 실용적인 개선 중 하나입니다. 빠른 재개에 필요한 충분한 컨텍스트를 보존하고, 불필요한 활성 연결 자원 사용을 줄이며, RNA를 통한 로컬 이동을 지원하고, NG-RAN이 페이징을 더 효율적으로 처리하도록 합니다. 그 가치는 균형에 있습니다. 완전한 유휴 상태에서 복귀하는 것보다 빠르고, 완전한 연결 상태를 유지하는 것보다 가벼우며, 현대 모바일 트래픽 패턴을 지원할 만큼 유연합니다.
