1. 논문 선정 이유
데이터 통신 및 네트워크 수업에서 노드,엣지,지연시간에 대해 배웠다. 새롭게 배운 지식을 다루는 연구라 지식을 명확하게 하기 좋은 논문이라 생각했고, 배운 지 얼마 안됐기에 흥미가 생겼다.
2.논문 분석 내용
서론)
버스정보시스템(BIS, Bus Information System)
- 무선망 기반 실시간관제시스템(ITS, Intelligent Transport Systems) 중 하나
- 설치된 GPS 단말기의 정보를 실시간으로 관제 시스템으로 전달하면, 관제 시스템은 GPS와 GIS 기반으로 정류장별 로 버스의 도착정보 등을 도출내는 시스템
- 국민 서비스 모델뿐 아니라 각종 버스 운행 정보를 제공하고, 행정부서에서 모니터링 및 관리에 필요한 운행내역을 제공하는 유용한 시스템
버스 정류장의 알림판이나 버스 도착 시간 알림 앱을 사용하는 일반 시민들이 BIS가 부정확하다는 의견을 제기.
원인을 세 가지로 볼 수 있음.
- 정보수집 주기에 따른 오차
- 버스에 부착된 GPS 데이터를 수집하는 네트워크 경로 구조에 따라서 불가피한 네트워크 지연이 발생,
GPS 데이터를 수집하는 서버에서 데이터 분석을 수행하기 위한 처리시간이 필요 - 사용자에게 데이터를 전달하는 갱신주기의 문제
노드에서 생성된 데이터가 BIS를 거쳐 가공된 후 서비스로 제공될 때 발생하는 지연시간을 시스템적으로 최소화하는 기법을 제안하고자 함.
엣지 클라우드 기반 BIS 데이터전송 모델)
1. BIS 구성과 동작 원리
BIS와 실시간 관제 시스템
시스템에서 필요로 하는 기능들의 조합 및 배치를 통해 개념도를 구축 후 현장에 적용하는 형태로 구축
버스에 장착되어 있는 센서들을 통해 수집된 정보를 통신 모듈을 통해 기지국 등으로 전달
-> 전달 받은 중앙 서버는 버스 정보를 기반으로 버스간 차량간격 및 실시간 버스 도착 예정 정보 생성
-> 정류소 안내 단말기 및 정보 및 실시간 버스 도착 예정 정보 생성
- 노드(버스나 철도 및 지하철): 데이터 생성, 연결되어 있는 통신 모듈을 통해 외부로 전송
- 로컬서버: 노드로부터 전달받은 데이터들 수집 및 전처리 후 유선 네트워크를 통해 중앙서버로 전달
- 중앙서버: 로컬서버로부터 전달받은 데이터 기반으로 분석 및 외부 데이터 참고하여 서비스 제공
- 사용자: 유/무선 망을 통해 중앙서버에 접속, 필요한 서비스 제공받음.
이 구조의 문제점
- 일반 사용자들이 필요로 하는 정보 전달받기 위해 로컬 서버가 아닌 중앙 서버에 접속해야 함.
- 관리자 역시 일부 지역 데이터 확인을 위해 중앙 서버에서 데이터 분석이 끝나기를 기다려야 함.
2. 엣지 클라우드 기반 버스정보관제 시스템
구조의 문제점을 해결하기 위해 노드가 로컬 서버로 데이터 전송하는 것이 아닌 로컬 서버와 중앙 서버의 기능을 모두 수행하는 클라우드 서버를 구축하고, 그 클라우드 기능 일부를 수행하는 엣지 컴퓨터 기능 적용
- 노드들은 센서로부터 수집된 정보를 무선 통신 모듈을 통해 클라우드 서버로 전송
- 클라우드 서버는 기존 로컬, 중앙 서버에서 수행하던 업무 수행, 데이터 분석 및 외부 데이터를 참고하여 서비스 제공
이 구조의 문제점
- 중앙 서버의 역할이 클라우드에서 수행하도록 바뀐 것 외에는 큰 차이 없음
- 외부 네트워크의 영향을 크게 받음
- 클라우드는 기존 중앙 서버에서 수행하던 역할 그대로 수행
- 엣지 노드는 로컬 서버가 수행하던 데이터 전처리와 수집 담당, 자신이 위치한 지역에서 수집된 데이터 분석 및 서비스와 정제된 데이터 제공
- 수집된 데이터는 엣지 노드에서 전처리 및 수집되어 활용되며 해당 내용은 클라우드로 전송됨
제안된 엣지 기반이 기존 BIS에 비해 얻을 수 있는 이득
- 기존 클라우드 시스템이 제공할 수 있는 확장성 및 유연성, 데이터 손실 방지 등의 장점
- 데이터가 로컬서버->중앙서버로 가서 분석되는 것이 아닌 수집된 지역을 담당하는 엣지노드에서 직접 분석 => 전송 지연 해결 가능
- 높은 서비스 신뢰성 기대 가능. 엣지 노드가 사용자 인근에 배치될수록 네트워크 문제가 발생할 가능성 작아짐. 네트워크 장애가 발생하여 클라우드와의 연결이 끊겨도 엣지노드가 해당지역 서비스 기능 제공 가능
데이터전송 시뮬레이션)
1. BIS의 전송지연 성능평가 모델
성능 분석을 진행하기에 앞서 가정
- 기존 로컬-중앙 서버 시스템과 클라우드 기반 시스템에서 네트워크 토 폴로지 외 구성요소들의 성능은 동일
- 성능 비교를 위하여 기존 BIS 와 엣지 기반 BIS 의 네트워크 토폴로지는 동일하며, 하나의 도메인에 위치하고 있으며, 중앙 서버는 해당 도메인의 중앙에 위치
- 엣지의 데이터 분석에 걸리는 시간과 중앙 서버에서 데이터 분 석에 소모되는 시간은 동일 <- 두 기기의 성능 차이는 존재하나, 각 기기가 다루어야 하는 정 보의 양이 다르기 때문이다
- 노드와 사용자의 APP 는 유사한 지역에 위치하여 동일한 엣지와 통신을 수행중
- AP(Access Point)는 노드와 사용자와 노드들이 접속하는 무선 단말기이자 스위치의 일종
- 노드는 데이터가 생성되는 곳, AP와 무선으로 연결됨
- APP은 사용자의 어플리케이션, AP와 무선으로 연결
- 네트워크 토폴로지의 크기는 AP에서 중앙 서버와의 거리인 h(ap-cen)과 비례
- AP와 엣지 노드 사이의 거리는 h(ap-edge)이며, 엣지 노드는 AP 를 포함한 스위치에 위치
| 파라미터 | 의미 | 비고 |
| h(ap-edge) | Number of hops between Ap and Edge nodes | Edge node is located in ap if 0 |
| h(ap-cen) | The distance between the Ap and the central server. Indicates the size of the network. | h(ap-lo) + h(lo-cen) |
| h(ap-node), h(ap-app) | number of hops between App to node or Ap – APP | It's connected directly, so 1 |
| α | Cost weight of the wired network | 0.5 |
| β | Cost weight of the wireless network | 1 |
| ESC (existing system cost) |
Cost spent on local central server systems from generating data to receiving data for users | |
| CSC (cloud system cost) | Cost of generating data from edge systems to receiving data from users |
성능 분석에 사용된 파라미터
ESC (existing system cost)
- 로컬 서버-중앙 서버 모델에서 데이터 생성부터 사용자가 데이터를 받기까지 소모되는 코스트
- ESC = β h(node-ap) + 2α( h(ap-lo)+h(lo-cen) ) + β h(ap-app)
- 노드에서 생성된 데이터는 무선으로 AP 로 전달되었으며, 해당 데이터는 로컬 서버를 거쳐 중앙 서버에서 가공되어 보관 및 서비스 됨. 사용자는 중앙 서버에게 서비스를 요청함
CSC (cloud system cost)
- 엣지 클라우드 서버 모델에서 데이터 생성부터 사용자가 데이터를 받기까지 소모되는 시간
- CSC = β h(node-ap) + 2 α h(ap-edge) + β h(ap-app)
- 해당 데이터는 엣지 노드에서 수집 및 가공되며, 사용자에게 서비스 됨. 사용자는 엣지 노드에게 서비스를 요청함. 수집 및 전처리된 데이터는 클라우드로 전송되나 본 논문에서 해당 부분은 다루지 않음
서버 및 노드에 탑재된 모듈들의 성능은 동일하다고 가정
2. 시뮬레이션 결과 분석
시뮬레이션 파라미터는 h(ap-edge)는 [0, h(ap-cen)-1], h(ap-cen)는 [4-8], h(ap-node)와 h(ap-app)
는 1, α는 0.5, β는 1 로 설정
엣지 노드의 위치를 고정시킨 상태에서 네트워크 사이즈를 변화시킨 결과, 엣지 노드는 AP 에 위치한 상태
Y 축은 노드에서 생성된 데이터를 사용자가 받기까지 소모된 코스트의 총합
X 축은 네트워크의 크기 별로 EST 모델과 엣지 노드와 사 용자의 거리값을 조정하며 CST 의 값을 계산
CST는 네트워크 사이즈의 영향을 받지 않음을 보임.
h(ap-cen)= 8 인 상태에서 엣지 노드가 이동하는 경우 CST 의 코스트 변화
엣지 노드가 APP으로부터 멀어짐에 따라 코스트가 비례하여 상승함을 보이고 있음.
그래프를 통해 판단한 제안 모델의 그래프의 특징
- 기존 모델은 네트워크의 크기와 비례하여 서비스를 제공하기 위한 코스트가 증가함
- CST 는 엣지 노드와 APP 이 멀어질수록 코스트가 증가하였다. 따라서 네트워크의 크기가 클수록, 사용자와 엣지 노드의 거리가 가까울수록 제안 모델의 효율이 상승함을 알 수 있음
결론)
시뮬레이션 결과 기존 모델은 네트워크의 크기에 비례하여 서비스 제공을 위한 코스트가 상승하였으며,
제안 모델의 경우 엣지 노드의 위치에 따라 코스트가 변경되었지만 기존 방식보다 10%-80%의 코스트 감소를 기대 할 수 있음을 보임.
따라서 BIS보다 실시간성이 중요한 중요한 정밀제어 관제 시스템 또는 무인 차량 관제 시스템 등의 경우 엣지 기반 시스템을 적용하며 엣지 노드를 현장 근처에 설치할 경우 기존 중앙 서버형 모니터링 시스템에 비해 높은 성능을 보일 수 있을 것으로 판단됨.
다만 본 논문에서 작성한 예시의 경우 노드와 사용자가 동일한 엣지 노드에 접속되어 있음을 전제로 하고 있으며, 최대의 효율을 내는 경우는 매우 많은 엣지 노드를 구축해야 하는 문제가 있어 이 두 부분에 대한 추가적인 연구가 필요함.
3. 배운 점 및 느낀 점
실시간 시스템의 성능을 향상시키는 데 있어 엣지 컴퓨팅이 중요한 역할을 할 수 있음을 이해하게 되었다. 과목을 수강하기 전에 이 논문을 읽었다면 분석할 시도조차 하지 못했을거고, 이해를 하는데 보다 많은 노력이 필요했을 것 같다. 제대로 된 논문 분석은 처음인데 생각보다 쉽지 않은 과정이었고 많이 해보면서 제대로 된 분석을 할 수 있도록 노력해야겠다.
'논문 분석' 카테고리의 다른 글
| API 호출 구간 특성 기반 악성코드 탐지 기술 (0) | 2024.11.11 |
|---|---|
| 갤럭시 워치를 중심으로 본 스마트워치 활용 기술유출의 위험성 및 대응방안에 대한 연구 (0) | 2024.10.30 |
| 강화된 안전쿠키를 사용한 웹 응용의 보안에 관한 연구 (0) | 2024.05.29 |
| IoT 환경에서의 네트워크 보안 프로토콜 성능 분석 (0) | 2024.05.15 |
| 스테가노그래피 소프트웨어 분석 연구 - 성능 비교 중심으로 (1) | 2024.05.01 |
