티스토리 뷰
센서들 끼리 ad hoc network를 구성하는것 처럼 보인다. 센서 네트워크의 목적에 맞게 mac protocol을 설계 해야 한다.
센서 네트워크는 환경 적응적이어야 하고, 노드의수가 많아도 동작해야 하며, 사람이 들여다 보지 않아도 동작해야한다.
또한 센서의 위치 변경이나 밀도 변경에도 적응적이어야 한다.
기존 네트워크에서 제일 중요했던 Fairness문제(특정 노드만 데이터를 수신)가 센서 네트워크에서는 중요하지 않다.
(노드들이 범용 목적이 아닌 특정 목적을 위해 존재하기 때문)
네트워크 내에서 처리하려면 패킷단위가 아니라 메세지(의미있는 데이터의 집합 ex파일) 단위 latency가 중요하다.
Fairness와 latency는 센서 네트워크에서 크게 상관없다.
에너지 효율, 충돌 피하기, 확장성,적응성이 더 중요하다.
이런 특성에 따라서 맥 프로토콜을 설계 해야 한다.
이것을 위해서 어디서 에너지가 많이 쓰이는지 파악 해야한다.
Collision이 일어나면 에너지가 많이 쓰이게 된다.
Control Packet도 오버헤드로 작용한다.
overhearing도 에너지를 많이 사용한다.
Long idle time 이후에 갑자기 bursty traffic이 발생한다.
이중에서 Idel listening이 제일 큰 에너지 소모 요인으로 작용한다.
따라서 Smac에서는
1. 주기적인 listen and sleep
2. 충돌 피하기
3. overhearing 피하기
4. 메세지 패싱
방법을 구현하였다.
long idle time을 줄이기 위해서 1.2초동안 120ms정도만 깨어있게 설계하였다.
대신에 주변 노드들과 언제깨고 언제 다시 잠들지에 대한 싱크를 맞춰야 한다.
하나의 노드가 주변 노드들에게 지금 sleep하는데 몇초 뒤에 깨겠다 라고 알려준다.(500ms)
왼쪽 원을 A그룹 오른쪽 원을 B그룹이라고 하자.
경계에 있는 두 노드는 양쪽 그룹 모두의 스케쥴에 맞게 깨어난다.
periodic listen and sleep을 하게 되면 내가 데이터를 전송할수 있는 기회,시간이 줄어든다.(sleep중엔 깰때까지 기다려야 하기때문에)
하지만 smac에서는 latency는 중요하지 않은 사항이었기 때문에 괜찮다.
충돌에 따른 에너지 낭비를 줄이기 위해 smac에서는 RTS/CTS를 이용한 Collision Avoidance를 사용한다.
RTS가 Collision Avoidance에 도움이 되려면 패킷의 크기가 데이터보다 훨씬 작아야 한다.
하나의 노드가 언제 sleep and wake할지 스케쥴을 주변 노드들에게 전송하고 각 그룹은 그에 맞게 행동한다.
경계노드는 스케쥴1,2 모두 맞추기 때문에 에너지를 더 사용한다.
이상태로 계속 놔두면 경계노드가 먼저 배터리가 다 닳을 것이다. 그래서 지속적으로 경계노드를 바꿔줘야 한다.
주기적인 sleep and wake -> duty cycling이라고 한다.
모든 노드들은 비컨 전달 주기가 있다. 그 주기 직전에 깨어난다. 이것과 유사하게
어떤 노드가 스케쥴을 쭉 뿌리면, 다른 노드들이 그 스케쥴에 따라서 다음에 깨어나야 될 시간이 정해진다.
모든 노드들이 스케쥴에 맞게 깨어나면 SYNC패킷을 전송하기 위한 정해진 시간내에 random back off를 통해서 SYNC를 서로에게 전송한다. random back off를 통해 충돌을 줄인다.
이 SYNC는 다음에 내가 얼마만큼 깨어있을것이고 언제 깨어날것이다 라는 정보가 들어있다. 이 구간에서는 SYNC패킷만 전송 되어야 한다.
SYNC패킷 구간 뒤에는 RTS,CTS를 위한 구간이 존재한다. 여기에서도 마찬가지로 random back off가 있어야 한다.
데이터를 교환하고자 하는 센더2와 센더3는 RTS,CTS를 정해진 구간내에 주고받은다음에 데이터를 주고받고 나머지 노드들은 sleep상태가 된다.
센더1은 주변 노드와 RTS/CTS를 주고받지 않았기 때문에 sleep모드로 들어갔다.
데이터 교환이 끝난 send2,3는 다시 sleep에 들어간다. smac은 1/10의 시간 정도만 깨어있게 설계 되었다.
위의 방식을 따랐을때 지연시간이 계속 증폭 된다.
사각형이 노드라고 생각해보자. duty cycling이 1초라고 해보자.
원래 sleeping을 안하는경우 한 노드에서 데이터 전송에 10ms에 걸린다고 했을때 총 20ms후에는 맨 왼쪽에서 맨 오른쪽까지 데이터가 전달 될것인데 데이터 교환이 끝나고 나면 sleep상태에 들어가야 하기때문에 강제적으로 1초를 기다려야 한다. 따라서 센서 네트워크의 크기가 커지는 경우
지연시간이 계속 증폭된다.
Adaptive listening을 통해서 이 문제를 해결한다.
3번 노드가 CTS를 받게되면 언제쯤 이 데이터 수신이 끝나게 될지 알게 된다. 1번 노드가 2번노드에게 RTS를 보내면 2번노드는 1,3번노드에게 CTS를 보낼것이다. 그럼 3번노드의 경우 1번과2번의 통신이 언제쯤 끝날지 알게 되는것이다.
그래서 통신이 끝날때쯤 잠시 일어나서, 지연시간 증폭 문제를 해결한다. 이때 3번 노드가 잠깐 일어나서 2번노드가 보내는 RTS를 수신할수 있게끔 한다. 이렇게 되면 데이터 수신시 한 주기 동안 기다려야 하는 지연증폭문제가 해결된다.
원래 주기 대로 일어나는 경우 데이터 전송이 원래 주기 바로 이후에 끝난다고 했을때 한주기를 더 기다려야 하지만,
원래 자신의 스케쥴대로 깨어나는게 아니라 CTS에 적힌 데이터 교환 시간 바로 직후에 깨어나면 이런 문제가 사라진다.
이것은 사실 1 hop에서만 영향이 있다. CTS는 1 hop까지밖에 전달 되기 때문이다.
따라서 Adaptive listening은 1주기동안 2hop까지 데이터가 전달 되게 끔 만들어줌으로써 지연시간을 반으로 줄였다.
Overhearing 줄이기
나에게 오는 패킷이 아닌데도 계속 그 패킷을 수신하는 것.
RTS를 받은 경우 내가 수신자 인지 아닌지 알게 된다. RTS를 받자마자 내가 수신자가 아니다 싶으면 바로 sleep상태로 들어간다.
Sender Receiver의 주변 노드들은 RTS CTS를 통해 자신이 주변 노드들이라는걸 알고 받자마자 Duration 필드를 보고 이 시간동안 sleep에 들어가서 깨어나지 않음으로써 overhearing을 줄여서 에너지 낭비를 막는다.
센서 네트워크에서 전송 단위는 메세지이다. 그래서 메세지 패싱이라고 부른다. 메세지는 논리적인 단위이다.
메세지가 뭔지인지는 어플리케이션에 따라 다르다. 패킷을 모아놓은것을 메세지라고 생각하면 된다.
어플리케이션에서 의미있는 데이터 묶음을 메세지라고 하는데 어플리케이션에 따라 메세지의 크기가 달라질것이다.
메세지 패싱
802.11에서는 메세지 단위가 한 패킷이다. 한 패킷마다 RTS/CTS를 교환하는데, 센서네트워크에서는 메세지 단위로 교환한다.
RTS/CTS를 교환한다음에 패킷 수십개를 보낸다
802.11에서의 fragment는 원래 하나의 패킷을 여러개로 쪼갠것이고, 센서 네트워크에서는 패킷 하나를 fragment라고 표현한다.
패킷 단위로 ack을 발생 시켜서 ack이 안올경우 패킷단위 재전송을 한다.
주변 노드들이 오랫동안 sleep할수 있게끔 해준다.(RTS/CTS에 메세지가 3주기 동안 sleep한다고 적혀있다)
RTS/CTS는 메세지 단위로 전송 된다.
RTS/CTS가 효율적인 메세지 전달 방법이 되었다.
메세지 단위로 RTS/CTS를 교환하면 RTS/CTS가 차지하는 오버헤드 비율이 굉장히 줄어들게 된다. -> 컨트롤 오버헤드를 줄인다.
컨트롤 오버헤드란 내가 네트워크에서 데이터 교환을 위해서 보낸 컨트롤 데이터의 양이다.(메타데이터)
정리
주기적인 listen and sleep
메세지 패싱, overhearing 방지, 충돌 피하기(random back off)등 맥 프로토콜 차원의 구현을 통해서 에너지 효율을 달성한다.
위의 기능들이 상호 연결 되어 있다. 메세지 패싱을 통해서 주기적인 리슨앤 슬립이 에너지 효율적으로 동작하는것이고, 메시지 패싱을 통해서 overhearing이 효율적으로 동작하고, 충돌 피하기도 효율적으로 동작한다.(RTS/CTS 메세지 패싱기법과 Random back off)
'컴퓨터 공학과 졸업 > 무선 네트워크' 카테고리의 다른 글
Wireless LAN(IEEE 802.11) - 2 (0) | 2017.12.09 |
---|---|
Wireless LAN(IEEE 802.11) - 1 (2) | 2017.12.09 |
Sensor network - 1 (0) | 2017.12.04 |
중간 Q&A (0) | 2017.12.04 |
wireless ad hoc network - 3 (OLSR,GPSR) (0) | 2017.12.02 |
- Total
- Today
- Yesterday
- return type
- atomic design
- webpack
- async
- reactdom
- Polyfill
- rendering scope
- javascript
- reducer
- promise
- typescript
- design system
- Action
- react
- mobx
- state
- storybook
- server side rendering
- type alias
- await
- reflow
- react hooks
- useEffect
- hydrate
- computed
- Next.js
- props
- Babel
- useRef
- es6
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |