티스토리 뷰
[TSC-2021] A Missing QoS Prediction Approach via Time-Aware Collaborative Filtering
SiO2whocode 2023. 1. 18. 13:12출처 : https://ieeexplore.ieee.org/abstract/document/9511220
요약
유저가 존재하는 수많은 서비스들을 모두 실행하는 것은 현실적으로 어렵기 때문에 QoS 데이터가 모인다고 해도 missing QoS값이 발생하는데 이는 정확한 QoS Prediction에 걸림돌이 된다. 또한 QoS 값을 예측함에 있어 outdated된 값들은 prediction 정확도를 저하시키기 때문에 QoS 데이터를 timeslice에 따라 나누어서 현재 시간과 가장 근접한 시간의 데이터가 중요한 역할을 할 수 있도록 하여 time-aware함을 달성하고자 한다. 이후 Collaborative Filtering 메서드를 사용하여 missing QoS 값을 예측함으로써 QoS Prediction 정확도를 높이고자 한다.
문제 시나리오(Motivation)
기존 접근방법들의 문제점
- QoS의 계산 시점이 다른 QoS 값을 이용한다면, 시간에 따라 달라지는 dynamic한 환경을 반영하지 못하는 문제
- 시간적 요소를 고려하지 않으면 similar user를 찾는 과정에서 오류를 범하게 된다. (similar하지 않는데 similar하다고 판단 or similar한데 similar하지 않다고 판단 - 구체적 시나리오를 설명함)
: 시간에 따라 환경 등, 상황이 달라지니 QoS 데이터를 다룰 때 시간적 요소를 고려해야한다.
이 논문 역시 historical multidimensional QoS value를 사용한다. 즉 이전 시간들의 QoS 데이터를 QoS 데이터 예측에 사용한다.
research issues
- Time-aware user-service QoS model
- 시간적 QoS 값을 반영한 QoS model을 개발하여 예측에 활용한다.
- Collaborative filtering based missing QoS Prediction
- historical temporal QoS값 전체를 활용하여 missing QoS prediction의 정확도를 향상한다.
1. Time-aware user-service QoS model
out-dated QoS value의 영향을 줄이는 것이 목표. 이전 데이터들 중에서 현재시간에 가장 가까운 시간 안의 데이터들만 선택한다. T는 현재로 부터 얼마나 이전의 데이터를 선택할 것인지를 나타내는 시간 범위의 값인데, 이 T의 값을 선택하는 것도 하나의 문제이다. 너무 크게 설정하면 outdated QoS value를 포함하게 되어 예측 정확도가 떨어지고, 너무 작게 설정하면 예측에 사용할 QoS 값의 개수가 줄어들기 때문이다.
2. Collaborative filtering based missing QoS Prediction
이 접근 방법의 절차는 아래와 같다.
- Similarity Computation
- QoS(value) normalization
말그대로 QoS 값을 [0,1]범위로 정규화 하는 과정이다. 정규화 과정이 필요한 이유가 논문에 구체적인 예시를 들면서 설명되어 있는데, 요약하면 QoS value가 response time이라고 할때, 두 유저의 response time 값이 9개의 경우에 많은 차이를 보이는데, 하나의 값이 아주 큰 값으로 동일하면, 그 하나의 큰 값으로 인해 실제로는 유사하지 않는 유저가 유사한 유저로 식별되는 문제를 소개한다. 평균의 오류로 생각하면 될 것 같다. 즉 이런 이유로 QoS 값을 일정 범위 내의 수로 정규화 하는 과정이 필요하다. 정규화 식은 흔히 정규화를 할 때 사용하는 식이다. (value - min_value / max_value - min_value) 논문에 나와있다. - Weighted PCC
가중치 계산. (이 논문에서 모든 방법들은 유저 based와 서비스 based 방법으로 나뉘지만 유저 based 방법을 위주로 설명한다) 두 유저가 동일한 서비스를 실행한 비율에 따라서 가중치를 다르게 둔다. 즉 같은 서비스를 실행한 비율이 많을 경우 더 높은 가중치를 두어서 그 유저의 값이 더 큰 영향을 미칠 수 있도록 하기 위함이다. - Time-Aware Similarity Computation
앞서 계산된 값에 time slice 를 적용한다. k개의 time slice를 사용하기로 결정했다면 그만큼의 데이터를 포함하여 similarity를 계산한다. 이때 similarity는 가중치와 정규화된 QoS 값을 곱하는 식이다.
- QoS(value) normalization
- Similar Neighbor Selection이 결과 similar user set이 도출된다.
앞에서 계산된 similarity 값을 통해 특정 임계값을 정하고, 그 임계값 보다 큰 similarity를 가진 유저들을 선별한다. TopN개의 similar유저를 뽑는 것이 목표인 경우 N개가 모두 모이거나 k개의 time slice를 모두 봤을 때 까지 선별 과정을 반복한다. (선별 과정을 가장 가까운 시간의 time slice부터 시작한다.) - Missing QoS Prediction
이 논문에서 제시한 식이 주어진다. 앞서 구해진 Similarity값과 UPCC(user-based PCC)값 등을 고려한 식인데, 정확한 원리에 대해서는 설명되어있지 않다..
personal thoughts
실질적으로 CF를 적용한 논문은 어떤 식으로 진행되는지 보고 싶어서 method부분을 꼼꼼히 읽었는데 마지막 equation을 사용한 이유에 대해서 자세하게 설명되어있지 않아서 왜 이런 식이 나오게 되었는지는 여전히 궁금한 상태다. 이런 식이 흔히 사용되는 식이라면 참고할 만한 내용을 언급해줄 수도 있었을 것 같은데 너무 당연한(?)식이라 자세히 설명하진 않은건가..여튼 어떤 식으로 접근하는지 method를 어떻게 전개하는지에 대해서 볼 수 있었다.
QoS value를 time slice에 따라 분류해서 일정 기간 안에 있는(현재 시간과 가까운 time slice에 속한 QoS value를 우선적으로 사용하는 등) 데이터만 사용하고 나머지 out dated된 데이터는 버린다는 접근 방법이 temporal factor을 고려한 QoS prediction이라는 목표에 기여함으로써 시간에 따라 달라지는 네트워크 환경의 dynamic한 속성을 고려하여 prediction 정확도를 향상시켰다고 볼 수는 있을 것 같은데, 여전히 user의 invocation context에서 고려해야 하는 점이 더 많이 있지 않을까 싶은 생각이다. 물론 현재의 QoS를 예측하기 위해서 근접한 시간의 값을 예측에 활용하는 것은 필요하다고 생각한다. 하지만 이것만으로 user의 invocation context를 모두 고려했다고 볼 수는 없을 것 같다.(논문에서 그렇다고 언급하지도 않음) 어떻게 특정 유저가 이 서비스를 사용할 때의 QoS를 정확히 같은 context로 계산할 수 있을까. 유저 디바이스의 노후화 정도, 동시에 실행되고 있는 서비스의 수 혹은 부하 및 비중, 네트워크 환경(이 논문), 유저의 서비스 사용 패턴 등..이런걸 모두 고려할 수 있으면 그때는 보다 정확한 QoS Prediction이 가능할까..? 이렇게 까지 할 필요가 있나? 이런걸 모두 고려하는게 가능한가? 그게 prediction인가 시뮬레이션 아닌가?
'Research Paper' 카테고리의 다른 글
- Total
- Today
- Yesterday
- 토마토
- 최소힙
- 백트래킹
- 다이나믹프로그래밍
- 파이썬
- 백준
- 브루트포스
- 최대힙
- 정렬
- 우선순위큐
- 트리
- 문자열
- BFS
- 그리디알고리즘
- 웹크롤링
- 투포인터
- Stack
- 수학
- 프로그래머스
- 게임이론
- dfs
- 스택
- c++
- 최단경로
- 동적계획법
- dp
- 이분탐색
- 알고리즘
- 자바
- Swift
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |