RRC Connection 되어있는 UE가 eNB나 상위 Layer로 부터 신호가 없을 때

어느시간이 지나면 RRC idle이 되나요?

규격상의 특정 시간이 정의 되어있나요??

(RRC connected --> RRC idle)

제가 알기로는 규격상 정의되어 있는 시간은 없으며, 사업자가 적당한 시간을 설정하는걸로 알고 있습니다.

RRC-Connected 상태에서 eNB가 단말이 일정시간동안 (예를들면 10초) 메시지가 없으면

UE Context Release Request (Cause=user inactivity)를 MME에게 전송하여 S1 Release를 시도합니다. 

참고삼아 국내 사업자의 경우 약 3~5초 정도로 설정해서 쓰고 있는 것으로 알고 있습니다. 

지나가다, 시간적인 여유가 있어, 답글 남깁니다. 질의하신 내용은 UE Inactivity timer 기능이며, 이 기능을 이용하여, RRC Connection된 후에 설정해 놓은 임의의 일정시간 동안, 신호가 없을때 신호와 상관없이, UE가 아무런 행동을 하지않아 서로 오고가는 Traiffic이 없을때, eNB에서 MME로 UE-Context release request를 하게 되고, 단말에서는 UE Context release complete 뒤에 RRC Connection release되어, Inactive mode(*idle) 로 바뀌게 하는 기능 입니다. 해당 관련 parameter의 range는 앞서 언급하신 것과 같이,3GPP-Spec에 명확하게 정의되어 있지않으므로(TS-23.401에서 관련된 설명이 나오기는 하나, 부족함) 각 vendor사에 정의된 range 및 default value가 상이합니다. 상세하게 언급해드리지는 못하지만, 대부분의 vendor가 수십초로 default 설정되어 있었으며, 구축 완료후 Traffic-Volume이 상당히 증가된뒤에 설정된 default 값이 품질에 영향을 주어, 국내/국외 vendor 나 사업자 구분없이 대부분의 global market에서 약10초 정도로 변경하여 사용하였습니다. 실례지만, 3~5초 면 상당히 짧은 시간인것 같은데, 10초에 비교하여, 짧은 시간으로 불필요한 자원을 더욱 효율적으로 제어/관리하고, UE-Power consumption등의 여러가지 benefit 이 있는 것은 이해하고 있습니다. 실제로 국내에서 해당 값을 사용하고 있다면, 어느 사업자 및 어느 vendor에서 그렇게 사용하고 있는 지 여쭤봐도 실례가 안될까요? 해당 파라미터는 eNB 혹은 ePC(NAS)에서도 Trigger 할수 있는 것으로 알고 있고, 언급하신 3~5초는 eNB에서 제어하는 UE-Inactivitiy timer로 가정한다고 했을때, 해당 inactivity timer trigger되는 조건이 해당 Vendor에서는, 모든 SRB and DRB을 포함하는 것인가요? 그리고, 호가 해제된 뒤에도, S1-Paging clycle에 의해서, ue가 paging 수신이후에 자동으로 RRC Connection request 시도 하는 경우도 있고,..S1 signaling과도 연관되어 너무 짧은 시간이면 Traffic volumn이 높은 지역의 eNB~MME에도 부하 생길것 같습니다. 혹시, Connected mode DRX Cycle 및 DRX-Inactivity timer는 어떻게 설정을 하셨는지요? 실제 User-experienced quality 기준으로 품질에 아무런 악영향이 없나 봅니다.

참고로, UE-inactivity timer관련하여, 논지에서 조금 벗어나긴 하지만, DRX-inactivity timer도 존재합니다. DRX같은 경우 Long/Short-DRX로 나누어 지며, Short DRX 같은 경우, 설정된 DRX-inactivity timer 완료뒤에 Short DRX Cycle timer가 별도 운용 되며, DRX-inactivity timer의 경우, DL/UL의 자원할당이후에 PDCCH-Subframe을 연속적으로 모니터링 한뒤에 해당 timer을 Control하고 있습니다.

곽건섭님이 추정하신 대로 제가 언급한 3~5초의 시간은 단말이 아닌

eNB에서의 UE Inactivity Timer 값을 의미하고 DRB를 대상으로 합니다. 제 설명이 좀 짧았네요.

제가 알기로 거의(?) 모든 RRC 관리는 단말이 아닌 eNB쪽에서 주도를 하고

사업자 튜닝 파라메터의 하나 (Paging 부하 vs 라디오 효율성) 로 보고 있는 것으로 압니다.

그리고 3~5초 정도의 IDLE Timer면 시간이면 정상적인 UDP 스트리밍이나 TCP 스트리밍/웹브라우징 트래픽에

대해 QoE 측면의 저하가 발생하지는 않을 것입니다.

그 외 사항에 대해서는 제가 사업자/주 분야가 아니라서 의견을 드릴 수는 없을 것 같네요. 

명쾌한 답변은 아니지만, 도움이 되었습니다. 감사합니다. 제가 궁금 했던 부분은 앞선 언급해 드렸던 것 과

같이, 

1) eNB에서 Trigger하는 UE-inactivity timer 값인지 / NAS UE-Inactivity timer인지?

   -> NAS UE Inactivity timer 의 default 값은 eNB에서 Trigger하는 UE-Inactivity timer에 비교하여, 당연히 짧을

      수 밖에 없으며, 대부분의 vendor가 3~4초로 사용 하고 있는 것으로 알고 있기 때문입니다.

2) 언급 하신데로 eNB에서 Trigger하는 값이라면, 특정 A vendor는 10초 / B vendor는 3~4초....

   -> B vendor에서는 아무런 리스크가 없고, 개선사항만 있다고 가정했을때, eNB자체 의 RRM 블럭의 Capability

       가 뛰어나거나, 혹은 다른 연관성이 있는 parameter..예를 들어,CDRX 사용여부..사용하고 있다면,

       어떻게 운용되어 지고 있는 지가 궁금했었는데, 아무튼 성실하게 답변 해 주실려고 노력 하신 점 

       감사드립니다.

보다, 정확한 정보 전달을 위하여, 추가 답변 드립니다. 언급드렸던 것 과 같이, 해당기능은 eNB에서 제어가능한 ue-inactive 관련 parameter는 무선자원을 제어하고, 관리하는 RRM 블럭과 연관성이 있으며, 관련규격의 "RRM-Config information element" 에서 아래의 Range값이 정의 되어 있으나, 실제 각기 벤더사에서는 1) eNB에서 제어 가능한 ue-inactivitity timer 와 2) Corenetwork에서 NAS(None Access Stratum) signaling을 통하여 제어 가능한, ue inactivity timer 의 range 및 default 값이 벤더사 마다, 각기 상이합니다.

ue-InactiveTime              ENUMERATED {

                                 s1, s2, s3, s5, s7, s10, s15, s20,

                                 s25, s30, s40, s50, min1, min1s20c, min1s40,

                                 min2, min2s30, min3, min3s30, min4, min5, min6,

                                 min7, min8, min9, min10, min12, min14, min17, min20,

                                 min24, min28, min33, min38, min44, min50, hr1,

                                 hr1min30, hr2, hr2min30, hr3, hr3min30, hr4, hr5, hr6,

                                 hr8, hr10, hr13, hr16, hr20, day1, day1hr12, day2,

                                 day2hr12, day3, day4, day5, day7, day10, day14, day19,

                                 day24, day30, dayMoreThan30}     OPTIONAL,