Beige Color

Google Colab을 이용하여 100개의 result csv 파일을 80개의 Training, 20개의 Test data로 분류하고 학습을 해 Decision Tree Feature selection을 진행하였다. 초기 생각했던 디자인과 다르게 각 노드의 Queue Length와 각 노드의 Throughput을 추가 데이터로 삽입하고 학습을 했다. 결과가 내가 생각한 Feature 들 만으로 DT가 잘 분류를 해냈으면 좋았을 텐데, DT의 Accuracy Score가 Training 0.509, Test 0.5104가 나왔다. 이것을 어떻게 받아들여야할지가 고민이다. Adhoc Network의 복잡성이 있는데 그 환경에서 DT가 0.5104의 Error rate을 낸다는 것은 어느정도 합리적이라고 봐..

우선 Colab을 이용하여 다음과 같은 과정으로 DT 를 이용해 Feature importance를 측정하고자 했다. 1. 100개의 데이터를 80 - 20 으로 Train - Test 분할한다. 2. PacketDropRatio를 Y-val로 하는 DecisionTreeRegression을 수행한다. 3. 중요도에 따라 Clustering에 사용할 Feature들을 결정한다. => 그러나 Regression의 결과 Score가 너무 좋지 않았다. 따라서, PacketDropRation를 0.25, 0.5, 0.75의 사분면으로 나누어 low-medium-medium2-high 로 범주화시키고, 이에 대한 DecisionTreeClassification을 하니 성능이 오르긴 했지만 충분하다고 생각되지 않..

구현의 목표 - 구현을 마치고, 해당 코드에서 뽑아낸 데이터를 기반으로 Feature Selection을 하면서 뭔가 이상함을 느꼈다. 우선 최종으로 포스팅한 코드에서 단순히 시뮬레이션을 100번 반복해서 100개의 csv를 뽑아내게 바꿨었는데, 해당 100개의 csv를 80개를 train, 20개를 test로 지정한 DT에서 Y-val인 Packet Drop (PhyRxDrop으로 측정함) 과 Neighbor Node와의 관계가 0.88이 나와버린 것이다. 조금 생각을 해봤는데, 우선 내가 측정하고 싶은건 "프토토콜의 변경으로 인한 PDR의 감소"인데 Phy에서 찍은거 자체가 말이 안되는 것 같다. 또한, NNeighbor가 많다면 자신이 path로 이용될 확률이 높아 그냥 drop 패킷 수가 높게 찍..

#include #include #include #include #include #include #include #include #include "ns3/energy-module.h" #include "ns3/wifi-radio-energy-model-helper.h" #include "ns3/device-energy-model.h" #include "ns3/adhoc-wifi-mac.h" #include "ns3/aodv-helper.h" #include #include #include #include #define TxRange 250 #define TotalTime 200 #define nodeNum 20 #define sinkNum 5 #define dataMode "VhtMcs8" #define..

이전에 작성한 코드로 구할 수 있었던 Attribute들은 서술하지 않음. * Queue Length 1. OnOff의 Qos Level을 AC_BE로 세팅 2. 각 노드의 AC_BE Queue 길이를 검사. * Node Score(Node Strength) 1. LET 배열을 전부 -1로 초기화 2. 이웃한 노드일 시, 주변 노드 수를 1 증가 시키고 다음을 수행. 2-1. 가까워 질 시, 해당 노드와의 LET를 -10으로 저장. 2-2. 멀어질 시, 해당 노드와의 LET를 식에 따라 계산 3. LET가 -1일 경우 이웃 노드가 아니고, -10일 경우 구한 LET 중 최대값에 1.5를 곱한 수를 Total에 더해준다. 그 외의 경우 그냥 LET 값을 Total에 더해준다. 4. 0.7*TotalLET ..

현재 토폴로지는 다음과 같다. node 의 수 : 50 wifi protocol : 802.11ac Transmission range : 350 m Routing protocol : OLSR app : PacketSink, OnOff Area : 1000 x 1000 m Speed : 0~20 m/s Mobility model : RandomWayPoint 교수님과의 미팅 결과 1. Feature를 우리가 좋다고 생각하는 것들이랑 실제랑 다를수도 있다. 그러니까 일단 최대한 좋다고 생각되는 feature들을 전부 구해서 DT에 먹이자. 그러면 DT를 통해 Feature selection이 가능할 것이다. 2. RandomWayPoint Model을 사용하였는데, 이 경우 특정 시간대의 각 노드 방향을 파..

이전 구현에서 구한 결과 csv 파일을 검토하던 중, 이상한 점을 발견했다. 일정 시간 이후에는 각 노드들의 Remaining energy가 반복되었던 것이다. 하여, 어떤 점이 문제일까 생각해보았는데, 각 노드들의 초기 에너지 세팅 값과 반복되는 energy 패턴에 연관성이 있음을 발견했다. 초기 에너지 세팅을 해준 값이 너무 작은 점, Trans&Recv 절차에 소모되는 에너지 양을 지나치게 크고, 통일 시킨 점이 문제로 생각된다. 따라서 에너지 소모 부분을 랜덤하게 세팅해주고, 코드를 재구성 하였다. 또한 전체적으로 다양한 랜덤 값을 가지게 코드를 변형하였다. #include #include #include #include #include #include #include #include #inclu..

이전 포스팅에 기록했던 곳에서 교수님과 상의 몇가지 아이디어가 추가되었지만, 우선 큰 골자를 디자인하겠다. 1. 시뮬레이션 상황 구현 준비 우선 Wireless Mesh Network, Mobile Adhoc Network, SDN, Centralized Dynamic Routing을 가정하겠다. 따라서 가정 시나리오는 다음과 같다. SDN controller는 각 node에 대한 정보를 알고있고, 이를 이용해 routing을 해준다. 그리고 GW에 연결이 가능한 노드들이 GateWay 노드가 되게 된다. 또한 각 노드의 성능의 차이를 주어야 노드 간의 level이 발생하게 되므로 노드들의 성능도 랜덤하게 주어야할 것 같다. 크게 나눠보면 Adhoc node에서의 라우팅 요청 -> SDN Controll..

이 글은 이전 포스팅에서 a. 어떤 objective를 사용하여 classification을 해주어야하는가? 를 해결하며 작성한 글이다. 일단 떠오르는 노드의 현재 상태를 평가할 수 있는 요소는 다음과 같다. 1. 현재 노드가 처리하고 있는 Traffic의 양.(Traffic load) 2. Queue-Length 3. 에너지 소비 4. 주변 노드의 갯수 5. 대역폭 6. Delay 이 점을 명심하고 논문들을 찾아봤다. A Clustering Routing Protocol for Mobile Ad Hoc Network(Jinke Huang, 2016)에 따르면, Clustering의 헤더를 정할 때 Link Experiation Time, Node's Relative Degree를 고려한다고 했다. An..

기존에 읽었던 IRSML에서 조금 더 나아가 새로운 Routing protocol을 제시해보기로 하였다. 다양한 아이디어를 교수님과 이야기 하였고, 현재까지 이야기 된 아이디어는 다음과 같다. 환경은 WMN(Adhoc Network), Centralized dynamic routing을 가정하며, SoftwareDefinedNetwork 이다. 1. 각 node들을 주어진 objective (아마 2개의 multiple objective를 돌려야할 것이다.)에 맞게 classification (Unsupervised learning) 해놓는다. 2. 1.의 단계에서 임시로 C1,C2,C3,C4의 단계로 노드가 분류되었고, C1