DEVOCEAN

안녕하세요! SKT AI Fellowship 5기의 11번 과제 『AI/ML 기반 단말 Power Saving 기술 개발』 프로젝트를 수행중인 팀 Seio의 유현민, 이종석, 김유빈입니다.

프로젝트 시작부터 약 3달의 시간 동안 저희 팀이 연구한 내용을 보고드리겠습니다.

앞서 연구 계획 포스팅에서 말씀드린 저희 팀의 연구 내용은 크게 두 가지, 저전력 AI/ML 모델 개발, 스마트폰 단말 데이터 수집 및 특성 분석이었는데요.

3개월 동안 스마트폰 단말과 XCAL 장비로 직접 데이터를 수집하여 DRX 동작을 분석하였습니다. 남은 기간 동안은 분석한 내용을 기반으로 저전력 AI/ML 모델을 개발할 계획입니다.

우선, 이번 포스팅에서는 저희 팀이 DRX 데이터 수집을 위해 기울인 노력과 함께 데이터의 분석 결과를 소개해드리겠습니다.

1. 연구 준비

AI Fellowship 프로그램 시작 후 약 2주 뒤에 XCAL-SOLO 모델을 수령할 수 있었습니다. 보조 배터리를 이용해 전원을 공급할 수 있고, XCAL 전용 스마트폰 앱을 통해 log를 수집할 수 있습니다.

그림 1. DRX 데이터 수집을 위한 XCAL-SOLO 및 스마트폰 앱

사용자가 스마트폰 단말을 사용하는 과정에서 발생하는 다양한 metric을 수집할 수 있으며, 저희 팀은 그 중 DRX 연구에 필요한 파라미터를 따로 파싱하여 연구에 사용하였습니다.

저희가 사용한 데이터를 DRX 동작과 함께 설명드리겠습니다. 이해를 돕기 위해 그림2를 통해 수집한 데이터들을 도식으로 표현하였습니다.

그림 2. DRX Cycle 및 events

• Subframe / system frame number (SFN) : 연구계획 포스팅에서, 스마트폰 단말이 데이터를 1ms 간격으로 데이터를 수신한다고 말씀드렸는데요.

  이 1ms 라는 데이터 수신 단위를 통신 용어로 ‘subframe’이라고 합니다!

  통신 시스템은 10개의 subframe을 묶어서 numbering을 하는데, 이를 system frame number (SFN)이라고 합니다.

  즉 하나의 SFN은 10ms의 시간을 의미하며, SFN은 0에서 1023까지를 한 주기로 합니다.

  한 주기의 SFN은 1024 × 10ms = 10240ms를 나타냅니다.

  쉬운 이해를 위해 그림 3을 첨부하였습니다. DRX event가 일어난 시간 순서를 나타내기 위한 time index라고 이해하셔도 좋습니다!

  
  

그림 3. Subframe / SFN 구조

• Downlink Grant, Uplink Grant : 수신할 데이터가 없어 sleep mode (off 구간)에 있던 단말은 일정 주기마다 PDCCH(Physical Downlink Control Channel)라는 제어 신호를 모니터링 및 디코딩하여 수신(downlink), 송신(uplink)할 데이터가 있는지 판단합니다. Downlink를 예로 들면, 단말은 ‘일정 주기’마다 ‘일정 구간’ 동안 기지국으로부터 PDCCH를 수신하고 디코딩합니다. 이 ‘일정 주기’가 바로 하나의 DRX cycle이 됩니다. 그림 2에 ‘Long Cycle’이라 이름이 붙어있는데, 주기가 좀 더 짧은 ‘Short Cycle’도 표준에 정의되어 있어 ‘Long Cycle’이라는 이름이 붙었지만, ‘Short Cycle’은 실제로 사용되지 않아서 Long Cycle = DRX Cycle이라 생각하셔도 무방합니다! 하나의 DRX cycle은 표준에 정의된 값 중 하나로 통신사가 설정할 수 있습니다. ‘일정 구간’은 그림 2의 on duration에 해당하며, 역시 표준에 정의된 값 중 하나를 통신사가 설정할 수 있습니다. PDCCH를 디코딩했을 때, 수신할 데이터가 없으면 단말은 다시 off 구간에 들어가게 됩니다 (그림 2의 deep sleep). 수신할 데이터가 있으면 off 구간에 들어가지 않고 그림 2처럼 inactivity timer를 발동하며, 지속적으로 PDCCH를 monitoring하며 데이터를 수신합니다. Inactivity timer의 동작이 종료되면 다시 off 구간에 들어가게 되는데, 그림에서 볼 수 있듯이 부분적으로만 off 구간에 머물게 됩니다. 저희 팀은 이런 cycle을 deep sleep과 구분하기 위해, partially sleep으로 명명했습니다. Inactivity timer도 마찬가지로 표준에 정의된 값을 선택할 수 있습니다. 한 가지 더 고려해야 할 것은, PDCCH가 수신되더라도 네트워크 상황에 따라 데이터를 수신할 수 있는 상황도 있고, 없는 상황도 있게 됩니다. 수신할 수 있을 때는 ‘ack’ 신호를 기지국으로 보내서 데이터를 수신할 준비가 되어있음을 알리고, 수신할 수 없을 때는 ‘nack’ 신호를 보내 데이터를 수신할 수 없음을 알립니다. UL Grant와 DL Grant는 이 ‘수신 가능 여부’를 나타내는 신호입니다.

• DL/UL Throughput : PDCCH 디코딩을 통해 송수신할 데이터의 유무를 파악했다면, throughput은 실제로 송수신한 데이터의 양을 나타내는 데이터입니다. 사용하는 어플리케이션에 따라 상이한 패턴을 보입니다.

• CDRX Events : Continuous Reception 모드에서 발생하는 DRX 이벤트에 대한 로그입니다.

  On duration, Inactivity timer, DRX cycle의 시작/종료 여부, PDCCH grant 여부가 시간을 나타내는 SFN과 subframe에 따라 기록되어 있습니다.

  DRX Cycle의 경우, 수집한 데이터에는 Long Cycle이라 명명되어 있습니다.

  그림 4와 그림 5는 각각 deep sleep과 partially sleep에서 발생하는 CDRX event의 예시를 나타냅니다 (SFN과 subframe은 보안상의 이유로 블라인드 되었습니다).

그림 4. Deep sleep 예시.

그림 5. Partially sleep 예시. (PDCCH가 grant되지 못하였을 때 발동되는 retransmission timer (RETX TIMER)도 기록되어 있지만, 복잡도를 낮추기 위해 연구 시 고려하지는 않았습니다.)

연구계획에서 말씀드렸듯이, 현재 DRX 동작에서 on duration timer, inactivity time, DRX cycle 등의파라미터들의 값은 고정되어 있습니다.

이 문제를 해결하기 위해 저희는 AI/ML 기술을 활용하여 유동적으로 파라미터의 값을 조절하고, off 구간을 조절할 수 있는 매커니즘을 개발하는 것을 목표로 정했습니다.

매커니즘 개발에 앞서, 현재까지 저희 팀 Seio는 데이터를 직접 수집하고 분석하여 파라미터 값의 조절 필요성을 연구하였습니다.

또한 사용자가 스마트폰 단말을 통해 이용하는 서비스는 매우 다양하며, 같은 서비스도 정지 및 이동 상태 여부에 따라 발생하는 트래픽 패턴이 상이합니다.

2장에서는 이런 다양한 서비스 시나리오에서 발생하는 DRX event의 분석 결과를 소개해 드리고,

고정된 파라미터를 변경했을 시 나타나는 off 구간 및 delay의 변화를 분석하여 변경된 파라미터의 실제 적용 가능성을 알아보도록 하겠습니다.

2. 연구 과정

현재 고정된 파라미터를 기반으로 하는 DRX 동작의 문제점을 파악하기 위해 저희가 세운 가설과 분석한 결과는 그림 6과 같습니다.

그림 6. 현존 문제점 분석을 위한 가설 설정 및 결과.

가설을 검증하기 위해, 우선 XCAL을 이용해 스마트폰 단말의 10가지 어플리케이션을 각각 정지 상태와 이동 상태로 나누어 수집하여 총 20개의 시나리오 데이터를 수집하였습니다.

10가지 어플리케이션은 아래와 같습니다.

1. Video Streaming - YouTube, Netflix

2. Video Chat – Zoom

3. Music Streaming- YouTube Music (YTM), Melon

4. Web – Naver

5. SNS – Kakao Talk, Instagram

6. Game - LoL, Kart rider

   첫 번째로는 20개의 시나리오마다 트래픽 패턴이 상이할 것으로 예상하고, 그에 맞도록 DRX 파라미터를 조절해야 할 필요성이 있다고 가설을 세웠습니다.

   하지만 정지 상태의 게임 시나리오를 제외하면, 특성이 다르게 나올 것이라는 가설과 다르게 트래픽 발생 패턴은 시나리오와 크게 관련이 없어 개선하기 어려움을 확인했습니다.

   그림 7을 보시면, 같은 동영상 플랫폼인 YouTube와 Netflix간의 일관성을 찾기 어려우며, 음악 스트리밍인 YTM과 Melon도 큰 차이를 보입니다.

   추가 조사 결과, 같은 시나리오에 대해서도 측정하는 시간과 장소에 따라 패턴이 상이했는데요.

   그 이유는, 시나리오의 종류보다는 여러 사람이 함께 접속하여 사용하는 네트워크의 상태에 큰 영향을 받기 때문입니다.

   게임 시나리오의 경우 요구하는 데이터가 지속적으로 이어지며, 안정된 네트워크에서는 데이터를 계속해서 수신할 수 있어 On 구간이 길게 이어지는 모습을 보입니다.

   
   

   
   

그림 7. 시나리오별 데이터 발생 패턴.

두 번째, on duration에 해당되는 default on 구간입니다.

On 구간 초반에 트래픽이 집중 발생하게 되면 on 구간을 단축하여 좀 더 빠르게 off 구간으로 접속할 수 있다고 가정하였으나,

분석 결과 on구간 전체에서 트래픽이 균일하게 발생하여 해당 파라미터의 조절 가능성이 낮다고 판단하였습니다.

그림 8과 표1을 보시면, 표에 기재된 평균 수치만 고려하면 조절이 가능할 것처럼 보이지만,

설정된 on duration의 중간 값 이후에도 최소 13%에서 최대 42%로 무시할 수 없을 만큼 많은 데이터가 발생하는 것을 확인할 수 있습니다.

따라서 현재 on duration timer는 적절히 설정되었으며, 이를 추가적으로 개선하기는 어렵다는 결론을 내릴 수 있었습니다.

그림 8. On duration 구간에서 첫 번째 데이터가 발생하는 시점.

표 1. Default On 구간 분석 결과

세 번째는 inactivity timer의 조절입니다. 데이터 발생 간격이 현재 설정된 inactivity timer에 비해 짧으면, inactivity timer의 길이를 필요 이상으로 길게 가져갈 필요가 없습니다.

따라서 inactivity timer 발동 이후 데이터가 발생하는 간격에 대해 조사했으며, 이를 시각적으로 나타내고 정리한 결과를 그림 9와 표 2에 나타내었습니다.

분석 결과, 대부분 설정된 inactivity timer보다 훨씬 짧은 간격을 데이터가 발생하는 것을 확인하였습니다.

다만 설정된 inactivity timer 값의 절반과 upper quatile (75%) 값 이상의 간격으로 데이터가 발생하는 경우는,

각 시나리오마다 약간의 차이는 있지만 대부분 시나리오에서 각각 3% 이내, 1% 이내의 적은 비율을 차지합니다.

따라서 특정 트래픽 상황에 따라 효율적인 inactivity timer가 있을 것으로 판단되며, 트래픽 발생 간격 특성에 맞고 energy efficient한 inactivity timer로 설정이 가능할 것으로 예상합니다.

짧아진 inactivity timer로 인해 발생하는 delay는 AI/ML 방안을 활용하여 최소화할 예정입니다.

그림 9. Inactivity timer 발동 후 발생하는 데이터의 간격

표 2. 트래픽 발생 간격 분석 결과.

*Upper quatile은 75% 지점을 의미하며, 예를 들어 inactivity timer가 100ms로 설정되었다면 75ms 이상의 간격으로 발생하는 데이터의 빈도를 나타냅니다.

마지막으로, DRX cycle 길이의 조절입니다. Deep sleep, 즉 트래픽 미발생 cycle 이 두 번 연속 이어지는 경우,

일시적으로 DRX cycle을 두 배로 늘려 on duration timer를 생략하여 power saving 효과를 높일 수 있다고 판단하였습니다.

이는 전체적인 트래픽 발생 과정에서 deep sleep의 비율이 partially sleep에 비해 높고, 평균적인 연속 등장 횟수가 높을 경우 큰 효과를 보일 것으로 예상됩니다.

그림 10과 표 3을 보시면, 대부분의 시나리오에서 트래픽 미발생 cycle의 연속 등장 횟수는 평균 2회 이내인 것으로 파악되었습니다.

따라서 DRX cycle 길이 조절 역시, AI/ML 기술을 활용하여 최적화할 수 있는 저희의 연구 대상으로 채택하게 되었습니다.

그림 10. 트래픽 미발생 Cycle 연속 횟수 빈도

표 3. 트래픽 미발생 Cycle 분석 결과

정리하면, 직접 스마트폰 단말을 이용해 데이터를 수집하고 분석한 결과 현재 DRX 매커니즘에서는 inactivity timer와 DRX cycle의 길이를 조절하여 더 효율적인 power saving 매커니즘을 개발할 수 있을 것으로 파악됩니다.

3장에서는, 남은 연구 기간 동안 저희가 활용할 AI/ML 알고리즘에 대해 소개하며 글을 마치겠습니다.

3. 향후 계획

그림 11. 조절 가능한 DRX 파라미터 및 delay 대응 방안

데이터 분석을 통해 파악한 DRX의 동작의 개선을 위해, 단말이 최대로 sleep할 수 있는 시간의 upper bound에 근접할 수 있도록 최적의 DRX 설정을 도출하기 위한 분석 계획을 세웠습니다.

먼저 트래픽 발생시 inactivity timer로 인해 연장된 on 구간에서는 마지막 트래픽 발생 직후에 on 구간 연장을 중단하면 최대한 길게 sleep할 수 있기 때문에

마지막 트래픽 발생 시점을 예측하여 불필요한 on구간 연장을 막고자 합니다.

두번째로 DRX cycle에서는 트래픽이 발생하지 않은 사이클이 2번 연속적으로 나타나면 cycle을 2배 증가하여 on duration 구간을 한번 생략하고자 합니다.

트래픽이 미발생 사이클이 2번 연속 등장하기 전의 패턴을 추출하여, 해당 패턴이 detection 되는 경우 DRX cycle을 미리 2배로 증가시킬 수 있도록 하고자 합니다.

Inactivity timer와 DRX cycle 조절 시, delay라는 side effect가 생길 수 있습니다.

원활한 서비스를 위해서는 변경된 DRX 적용 후 발생하는 delay를 최소화해야 하기 때문에 변경된 parameter를 적용했을 때 delay를 예측한 뒤 최적값을 도출할 예정입니다.

그림 12. AI/ML 기반 DRX 파라미터 조절 알고리즘

이를 위해 저희는 수집한 패턴을 시계열로 모델링하고,

시계열 데이터 연구에 사용되는 AI/ML 알고리즘인 pattern recognition / forecasting / clustering / change point detection을 이용해 최적의 DRX 파라미터를 도출할 계획입니다.

Pattern recognition을 통해 수집한 트래픽 패턴을 토대로 forecasting을 통해 시계열 데이터를 예측합니다.

그 후 유사한 패턴별로 클러스터링하여 같은 클러스터에 포함된 패턴에는 동일 DRX 설정을 적용합니다.

발생 데이터의 패턴이 다른 클러스터에 포함되는 패턴으로 변경될 경우, change point detection을 통해 이를 감지하여 설정 변경을 수행하여 power saving 효과를 높이는 알고리즘을 개발하도록 하겠습니다.

이상으로 저희 팀 Seio의 연구 과정 포스팅을 마치겠습니다. 최종 발표 이후에는 실제 시스템에 기여할 수 있는 유용한 결과와 함께 찾아뵙도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다!