안녕하세요! 저희는 SKT AI Fellowship 5기에서 “5G MEC (AWS Wavelength) 기반 데이터 트래픽 성능 최적화 방안 연구” 연구과제를 수행하게 된 SKTM(SK To The Moon) 팀입니다.

이번 포스트에서는 저희가 진행하는 연구 소개 및 계획에 대해서 다뤄보도록 하겠습니다.

1. 기술 소개

과제 배경

• 5G MEC

  
  

  Mobile Edge Computing(MEC)은 클라우드 환경을 모바일 단말기와 가장 가까운 네트워크 인프라 내부에 구축함으로써 초광대역 및 초저지연 서비스를 제공하는 혁신적인 기술입니다.

  2018년 5G 시대의 도래와 함께, 5G의 고신뢰성 및 저지연 통신 특성을 충족시키는 방법으로 MEC 기술이 각광받기시작했습니다.

• AWS Wavelength

  
  

  AWS Wavelength는 5G 전용망을 통해 모바일 디바이스에게 제공되는 Mobile Edge Computing입니다.

  인터넷 상의 예측 불가능한 대역폭 및 레이턴시의 영향이 없어 저지연 서비스에 적합합니다.

  국내와 같은 경우에는 AWS 서울 Region에 전용회선으로 직접 연결되어 있어 예상 가능한 응답시간을 제공합니다.

연구배경

wavelength 대표 usecase를 분석하여 다음과 같은 5가지의 기술 요소를 찾았습니다.

1. 대용량 데이터 송수신

2. 오프로드 GPU 가속연산

3. 모바일 디바이스와의 초저지연 연결

4. 데이터 기반 모니터링

5. 실시간 디바이스 원격 제어

저희 팀은 미래 모빌리티의 핵심 기술에서 해당 5가지 기술 요소의 장점을 극대화

할 수 있는 Use Case를 발견할 수 있었습니다.

기존의 차량 자율주행 시스템은 차량 내부에 탑재된 임베디드 컴퓨터에서 인지, 판단, 계획, 제어의 전 과정을 수행합니다.

이 과정에서 임베디드 컴퓨터의 성능 한계와 많은 전력 소모량이 발생하며, 이는 고성능 알고리즘(DNN 기반 Object Detection 및 Tracking 등)의 구동에 많은 제약을 가져 옵니다.

그 결과, 더 높은 성능의 컴퓨팅 장비를 요구되며, 이는 고비용을 초래합니다.

하지만, 이런 문제점은 Device와 가까운 Edge Cloud에 컴퓨팅을 오프로드(off-load)함으로써 해결될 수 있습니다.

Edge Cloud를 활용하면 고성능 컴퓨팅을 수행할 수 있을 뿐만 아니라, 실시간으로 차량 간 데이터의 송수신과 원격 제어가 가능해집니다.

또한, Edge Cloud에 연결된 차량을 중앙에서 관제하고 제어할 수 있으므로 차량 상호작용이 필수적인 군집 주행을 수행하기 유리합니다.

이릍 통해 저희 팀은 SKT 5G MEC의 장점을 극대화하고자 “자울주행 Computing을 5G Edge Cloud로 오프로드 한 군집 자율주행 인프라 구축” 을 연구 과제 아이디어로 선정하게 되었습니다.

연구목표

저희의 연구 과제는 크게 “엣지클라우드의 오프로드 자율주행”, “클라우드 기반 군집주행”과 “시스템 성능분석 및 최적화” 세 가지 목표를 설정했습니다.

1. Edge-Cloud offloading한 자율주행

   • Wavelength를 통한 차량 센서 데이터 처리 및 주변 환경 인지, localization

   • Wavelength를 통한 차량 피드백 제어

2. 클라우드 기반 군집주행

   • 차량의 군집 주행 계획

     • 군집 생성 및 제거

     • 개별 차량의 군집 합류 및 이탈

     • 군집 별 리소스 할당

   • 군집의 전역 경로 계획

3. 시스템 성능분석 및 최적화

   • 성능분석 지표 및 도구 선정

   • 성능 모니터링

   • 최적화 방안

2. 연구 과제 아이디어

시스템 제안

• 시스템 개요

  저희 과제의 전체 시스템 개요는디바이스(차량), Wavelength(엣지), 클라우드로 이루어져있습니다.

  각 차량은 Wavelength에 주변 환경을 인지할 수 있는 센서 데이터와 속도, 방향 등 상태 데이터를 전달하고 주행을 위한 제어신호를 수신받게 됩니다.

  Cloud는 차량과 군집의 상태, Wavelength의 자원을 관리합니다.

  마지막으로 이 과제의 핵심인 Wavelength는 수신받은 센서 데이터로부터 인지, 계획 및 판단, 제어로 이루어진 자율주행의 전 과정을 수행하여 각 차량에게 제어신호를 전달합니다.

  
  

1. 디바이스 (차량)

   각 차량은 Nvidia Jetson Nano라는 저전력 임베디드 컴퓨터를 탑재합니다.

   이는 차량에 탑재된 각종 센서데이터를 5G 모뎀을 통하여 Wavelength에 송신하고, Wavelength로부터 제어신호를 수신받아 차량을 구동합니다.

   
   

2. Wavelength (엣지)

   Wavelength는 차량의 자율주행을 수행하기 위한 모듈을 구동합니다.

   크게 Perception, Planning, Control 노드로 이루어진 자율주행 모듈과 차량과 데이터를 주고받기 위한 Peer Manage 모듈로 나누어집니다.

   perception 모듈은 차량의 센서데이터로부터 Lane detection, Object Detection 등 Machine Learning에 기반한 환경 인지를 수행합니다.

   Planning 노드는 Perception 노드로부터 전달받은 차선 정보, 장애물 정보와 Cloud로부터 전달받은 군집과 각 차량의 목적지를 고려하여 차량의 지역 경로를 계획합니다.

   
   

3. 클라우드

   시스템의 클라우드는 AWS Seoul Region의 Public Cloud를 사용하여 구축합니다.

   이는 VPC로 연결된 Wavelength의 데이터를 통해 전체 군집과 차량을 관제하고, 군집과 차량 별 전체 경로를 관리하는 역할을 수행합니다.

   크게 군집의 생성과 삭제, 차량 별 군집 합류, 이탈 명령, 경로 최적화 등의 기능이 있으며 이에 따른 군집의 크기 변화에 대응할 수 있도록 각 군집에 컴퓨팅 리소스를 할당할 수 있습니다.

   
   

연구 내용

• Device-Edge offload 자율주행 시스템

  • Device-Edge FlowChart

    차량(Device)와 Edge 간의 흐름도입니다. 차량은 상태정보와 센서 데이터(RGB-D 이미지)를 Wavelength의 브로커에 전송합니다.

    각 군집의 자율주행을 수행하는 Platoon Operator는 브로커로부터 차량들의 데이터를 전달받습니다.

    RGB-D이미지로부터 lane detection, object detection 등 차량의 주변 환경을 인지하고 계획 및 판단, 제어를 담당하는 “Nav2” Navigation system에 결과를 전달하게 됩니다.

    Nav2는 이를 통해 차량의 다음 지역경로를 생성합니다. State 데이터는 차량의 현재 속도, 방향 등을 담고 있습니다.

    이는 Nav2 시스템에게 전달되어 목표하는 차량의 상태와 비교하고, 다음 제어신호를 차량의 구동부 제어기에 전달합니다.

    
    

  • Device-Edge Timing Diagram

    실시간 원격 자율주행을 가능케 하기 위해 차량과 Wavelength 간 송수신하는 메시지의 포맷과 주기, 처리시간을 결정해야 합니다.

    이들은 차량이 자신의 상태와 환경에 따라 다음 행동을 결정하는 반응속도에 영향을 미칩니다.

    저희는 이를 위해 Timing Diagram을 활용하여 Device와 Edge간의 상호작용을 나타냈습니다.

    이는 시스템을 구성하는 모듈이 메시지를 송신하기부터 수신하여 처리를 완료하기까지의 전 과정을 시간의 흐름에 따라 확인할 수 있습니다.

    아래의 그림은 한 packet 당 전체 delay를 3ms로 가정하여 피드백 제어 주기는 10ms, 이미지 데이터 수신 주기는 100ms로 설계하였을 때의 타이밍 Timing Diagram입니다.

    
    

    크게 두 가지 과정이 나타나있는데, 먼저 차량으로부터 상태정보(state)를 수신하여 목표하는 상태에 도달할 수 있도록 제어 신호(control profile)를 전달하는 피드백 제어 과정이 있습니다.

    두 번째로는 차량의 센서 정보(RGB-D image)를 수신해 주위 환경을 인지하고 차량의 다음 경로를 계획하는 과정이 있습니다.

Wavelength에 구현된 기능이 해당 설계를 충족하는지 확인하기 위해 각 과정에 대한 성능분석이 필요합니다.

예를 들어 제어신호의 경우 전체 delay가 저희가 설계한 제어 주기보다 길어 반응속도보다 제어주기가 빠르다면, 설계 제어주기를 낮추는 형태로 수정해야할 것입니다.

만약 상태 정보로부터 제어신호를 생성하는데 너무 오래 걸린다면 가벼운 제어기를 사용하거나 높은 성능의 instance를 고려하겠죠.

저희는 각 상호작용에 대해 Delay, Processing Time, jitter 등의 성능 지표를 분석하고 설계 요소(메시지 주기, 사이즈, 알고리즘, …)를 수정해가려고 합니다.

• Edge-Device Data Schema

  Edge와 Device간 송수신하는 메시지의 종류는 다음과 같습니다. 저희는 각 메시지마다 구조와 프로토콜, 전송주기를 결정하였습니다.

State (Device → Edge)

{
  "name": "state",
  "protocol": "MQTT",
  "period" : "10ms",
  "header": [
    "timestamp":"",
    "frame_id":""
  ],
  "body": [
    "velocity(float32)":"",
    "heading(float32)":""
  ]
}

RGB Image

{
  "name": "RGB_Image",
  "protocol": "RTSP",
  "period" : "100ms",
  "header": [
    "timestamp":"",
    "frame_id":""
  ],
  "body": [
    "width(int8)":"",
    "height(int8)":"",
    "format(string)":"",
    "data(int8[])":""
  ]
}

Depth Image

{
  "name": "RGB_Image",
  "protocol": "RTSP",
  "period" : "100ms",
  "header": [
    "timestamp":"",
    "frame_id":""
  ],
  "body": [
    "width(int8)":"",
    "height(int8)":"",
    "format(string)":"",
    "data(int8[])":""
  ]
}

Control Signal

{
  "name": "control_signal",
  "protocol": "MQTT",
  "period" : "callback",
  "header": [
    "timestamp":"",
    "frame_id":""
  ],
  "body": [
    "throttle_output(float32)":"",
    "steering_motor_output(float32)":""
  ]
}

• 테스트 및 성능분석

  위에서 언급한것과 같이 저희는 차량과 Wavelength 간 이루어지는 상호작용에 대해 성능 분석을 진행할 계획입니다.

  • 성능지표 선정

    차량으로부터 송신된 센서 신호가 Wavelength에서 처리되어 차량이 제어신호를 수신하기까지의 지연시간(end-to-end latency)이 제어 주기 이내로 작동하는지 확인하는 것을 우선으로 하였으며,

    그에 따른 다양한 성능지표도 분석할 것입니다. 각 메시지 포맷 (상태 정보, 제어 신호, 이미지 데이터)에 따른 분석과 그에 맞는 최적화 또한 진행할 것입니다.

    • End-to-End latency

    • Round-Trip Time

    • processing delay

    • Network Bandwidth

    • Jitter

  • 분석 방법

    각 지표 별 평균, 분산, 중앙값으로 대략적인 추이를 판단할 수 있습니다.

    성능 테스트를 통해 획득한 데이터를 기반으로 연속 확률 분포 모델을 그리거나, 작동시간이 흐르며 작동 후 경과시간에 따른 지표 변화를 확인할 수 있습니다.

    
    

    위 지표를 분석하기 위해 다음과 같은 툴을 사용할 수 있습니다.

    • iperf :대량의 트래픽을 발생시켜 bandwidth를 측정할 수 있습니다. 업링크, 다운링크에 대해 모두 측정할 수 있으며 TCP, UDP 전송 모드를 지원합니다.

    • smokeping:네트워크 상태를 확인하기 위해 흔히 사용되는 툴인 ping과 유사합니다. latency의 분포와 packet loss를 측정하고 저장하며 모니터링할 수 있는 대시보드를 제공합니다.

    • 프로메테우스-그라파나 : 프로메테우스-그라파나 : kubernetes환경에서 각 노드를 모니터링할 수 있습니다. 네트워크 I/O와 함께 CPU 및 메모리 사용량 등을 분석할 수 있습니다.

  • 분석 결과에 따른 최적화

• 저희는 분석 결과를 통해 기존의 클라우드 컴퓨팅과 Wavelength를 비교하고 구현한 시스템을 최적화할 예정입니다.

  • 5G MEC는 최근 제안된 기술인 만큼 다양한 usecase를 통한 검증과 기존 Cloud 컴퓨팅 서비스와의 비교가 필요합니다.

    Wavelength를 적용한 저희 시스템이 기존 Cloud 컴퓨팅만 사용했을 때보다 어떤 점이 개선되었는지, 어떻게 효율적으로 사용할 수 있는지 알아볼 것입니다.

  • 실제 적용 시 저희가 예상한 것보다 성능이 낮을 수도 (가설이 틀렸을 수도), 혹은 더 다양한 알고리즘을 적용할 수 있을 만큼 높은 성능을 지닐 수도 있습니다.

    네트워크 성능이 가설보다 낮다면 패킷 사이즈를 줄이거나 제어 주기를 길게 수정하는 등의 최적화를 수행할 수 있습니다.

    자율주행이 어려울 정도의 성능이라면 제어 알고리즘만 차량에서 구동하는 형태로 설계를 변경할 수 있습니다.

    예상보다 네트워크 대역 폭이 낮다면 이미지 압축률을 높이거나 RGB이미지 대신 grayscale 이미지로 환경인식을 수행할 수 있습니다.

    네트워크 성능이 가설을 상회할 경우 차량에 추가적인 센서를 장착하거나 제어주기를 단축할 수 있습니다.

    이 경우 주변 환경을 인지할 수 있는 다양한 데이터를 wavelength에 전송할 수 있고 정밀한 제어가 가능하기에 복잡한 환경에서도 저희의 서비스를 적용할 수 있을 것입니다.

    이후 차량의 수의 증가(scale-out), 데이터 크기의 증가, 제어 주기 단축 등의 부하 테스트도 진행할 예정입니다.

    위 경우 차량의 위치에 따른 기지국의 차이, 차량 별 성능 차이에 대한 추가적 변인 또한 고려하여 성능 분석이 필요합니다.
    

    실제 환경을 차량을 도입하여 실험을 진행하기에는 어려움이 있으므로 우선 실물 Robot과 시뮬레이터를 혼합한 환경에서 자율주행 차량을 모사하여 테스트를 진행할 계획입니다. 저희 팀이 사용할 Robot은 다음과 같습니다.
    

연구계획

연구 계획은 언제든지 유동적으로 변경될 수 있습니다!!

팀 소개

SKTM 팀명의 의미는??

SK To The Moon의 약자로, OO To The Moon 이라는 팀명을 저희 연구실에서 오랫동안 사용해 왔습니다.

여러가지 의미가 담겨 있는데, 저희 지도교수님에 대한 존경심도 담겨 있고, 저희 프로젝트가 하늘로 뚫고 날아오를 것이라는 이중적인 의미를 담고 있습니다.

멘토 및 팀원소개