티스토리 뷰
지난 포스팅 정리
미디움이 프리가 될때 프레임의 종류마다 따라야 하는 대기시간이 존재한다 이것을 interframe spacing이라고 한다.
이것을 통해서 패킷간 우선순위를 해결할수 있고, 802.11의 3가지 프로토콜 공존문제를 해결할수 있었다. 또한 컨텐션 윈도우를 통해 노드간 충돌을 방지한다.
컨텐션 윈도우는 환경적응적으로 동작해야 하기 때문에 가변적이어야 한다. p-persistence csma/ca에서는 p를 결정할때 노드의 숫자인 N에 따라서 결정했었다. (N*P<1인 P) 하지만 802.11에서는 패킷을 보냈을때 ack가 오지 않을경우 충돌이 일어났다고 생각하고 컨텐션 윈도우를 2배로 늘린다. 그렇게 되면 각 노드가 기다려야 하는 시간도 2배로 늘어날수 있다. 0~7사이의 숫자를 뽑는거보다 0~15까지의 숫자를 뽑았을때 충돌 확률이 낮아질것이다.
무선 네트워크 상황에서는 대기시간이 길어지는 한이 있어도 최대한 충돌을 피해야 성능이 늘어난다.
충돌이 날때마다 컨텐션 윈도우 사이즈를 2배로 늘린다. 최대 컨텐션 윈도우 사이즈가 지정 되어있는데 이 크기가 될때까지(256) 계속해서 늘린다.
충돌이 일어났다 => ACK가 오지 않았다. p-persistency csma/ca방식에서는 충돌이 일어나면 그냥 무시했었다.
미디움을 센싱 했는데 free상태라고 하면 DIFS만큼 기다렸다가 데이터를 전송한다.
센싱했는데 미디움이 BUSY인경우 DIFS만큼 기다렸다가 Contention window를 통한 random back off를 한다음에 데이터를 전송한다.
3개의 노드가 동시에 컨텐션 윈도우에 진입한 경우 작은 컨텐션 윈도우를 뽑은 노드가 먼저 전송하게 된다.
0뽑은 노드가 먼저 전송하고 7뽑은 노드는 자신의 차례가 되어서 전송하려고 봤더니 미디움이 비지상태 이므로 DIFS를 다시 기다리고 컨텐션 윈도우를 다시 뽑게 될것이다.
화살표는 Layer2에 패킷이 도착한것을 의미한다.
맨처음에 station3에 패킷이 도착했는데 미디움이 free이므로 DIFS만큼 기다렸다가 데이터를 전송하게 될것인데, 기다리는동안 station1도 패킷전송 요청이 들어왔다. 1번 2번 5번 3개의 노드는 3번 스테이션의 전송이 끝나자마자 DIFS만큼 기다리고 나서 컨텐션 윈도우에 들어가게 된다.
노드마다 컨텐션 윈도우 사이즈는 달라질수 있다. 1,2,5번 노드중에 2번이 제일 작은 컨텐션 윈도우를 뽑았기 때문에 제일먼저 데이터 전송을 시작하게 된다.(elapsed-> 지난 residual->남은) 그리고 나서 station4에 데이터가 도착했는데 미디움이 busy이므로 DIFS동안 기다렸다가 다시 컨텐션 윈도우를 뽑는다. 이때 스테이션5와 같은 컨텐션 윈도우를 뽑아서 충돌이 일어났다.
그래서 스테이션4와5의 컨텐션 윈도우 사이즈는 다른 노드들보다 2배가 늘어난 상태로 다시 컨텐션 윈도우를 뽑을것이다.
나중에 전송이 성공하면 다시 컨텐션 윈도우는 기본 사이즈로 돌아오게 된다.
컨텐션 윈도우를 무한정 늘리지 않고 시스템에서 정해진 횟수만큼만(7~9회) 늘리게 된다.
전송이 실패한 경우 MAC Layer에서 재전송을 하다가 계속 충돌을 하게 될 경우 결국에는 패킷을 버리게 된다.
멀티 캐스트(일부한테만 보내는것) 패킷 같은 경우에는 ack가 없다. 유니캐스트 패킷만 ack가 존재한다.
내가 데이터를 보내려고 의도한시점에 carrier sensing을 하는데 미디움이 free인 경우 컨텐션 윈도우 없이 DIFS만큼만 기다렸다가 전송하고,
리시버는 CRC(오류 확인 코드)를 확인하고 문제가 없는 경우 SIFS만큼 기다렸다가 ACK를 보낸다.
다른 노드가 데이터를 보내려고 할때 DIFS만큼 기다렸다가 컨텐션 윈도우를 거친다음 데이터를 전송한다.
전송에 실패한 경우 자동으로 컨텐션 윈도우를 2배로 늘리고 다시 컨텐션 윈도우를 뽑아서 재전송하게 된다.
RTS/CTS는 유니캐스트에서만 존재하는데, 멀티캐스트 혹은 브로드캐스트에서 모든 노드가 CTS/RTS를 수신하기 어렵기 때문이다.
주변 노드들은 RTS를 받거나 CTS를 받으면, 이 안에 데이터를 보내고 ACK까지 주고 받는데에 걸리는 시간을 보고 그 시간 동안 캐리어 센싱을 하지 않고 끝날때 까지 대기한다. NAV(Network Allocation Vector)
carrier sensing하는것 자체가 에너지 소모가 큰 행위 이므로 NAV를 설정한다.
이것을 Virtual Carrier Sensing이라고 한다.
패킷의 1000~1500bit중에 한비트라도 오류가 난 경우 패킷 전체를 버려 버린다.
패킷단위로 오류 발생 여부를 체크한다. 이런 문제를 해결하기 위해서 패킷을 더 잘게 쪼개서 보낸다.
이것을 fragmentation 이라고 한다 (단편화)
오류의 확률은 패킷의 길이에 비례한다.
패킷 길이가 1000bit인데 1bit 오류확률이 p라고 할 경우 패킷이 성공적으로 전송 될 확률은 (1-p)^1000이다.
위의 그림은 RTS/CTS + Fragmentation을 한 사례를 보여주는것이다.
첫번재 frag1에 대한 ack가 오지 않을 경우 재전송 한다. frag들은 연속적으로 전달 되야 의미가 있기 때문에 DIFS가 아닌 SIFS만큼만 기다렸다가 전송한다.
RTS와 CTS는 NAV를 설정한다고 했었다.
RTS의 경우 첫번째 fragment에 대한 ack를 수신할때 까지의 시간을 기록하고
CTS도 마찬가지로 ack 수신 까지의 시간을 기록한다.
첫번째 frag를 받은 receiver가 아닌 다른 노드들은 내가 이때 데이터를 전송해봐야 어차피 충돌이 날것이기 때문에
이 frag속에 있는 데이터 전송 시간을 보고 그 시간동안 기다린다.(NAV(frag1))
마찬가지로 첫번째 frag에 대한 ack를 받은 경우 그 ack에는 다음 frag의 ack수신까지 걸리는 시간에 대한 길이 정보가 있기 때문에
첫번째 frag의 ack를 받은 sender,receiver를 제외한 다른 노드들은 그 시간동안 대기했다가 데이터를 전송하게 될것이다.
fragmentation의 단점 - 패킷을 보낼때마다 일정시간을 기다려야한다(SIFS,DIFS등등)
또한 각 패킷의 헤더에 대한 오버헤드가 크다.
아까전에 PHY 헤더는 전송속도가 빨라져도 최저속도로 전송된다고 했었다. payload부분은 속도가 빨라 질수 있지만 헤더는 최저속도로 전송 되기 때문에 이것이 굉장히 큰 오버헤드로 작용한다.
fragment를 하게 되면 전송 오류 확률은 줄어들지만 대신에 오버헤드가 커진다(패킷을 쪼갤수록 추가되는 헤더가 많아지므로)
따라서 패킷을 여러개 합쳐서 보낸다. fragment의 반대되는 개념으로 aggregation이라는것이 있다.
PCF 맥 프로토콜
지금까지 우리는 DCF라는 CSMA/CA기반의 802.11의 맥 프로토콜을 살펴 보았다.
하지만 PCF라는 맥 프로토콜도 존재한다고 했었다.
하지만 거의 사용되지 않는 맥 프로토콜이다.
ap가 있을때만 동작 가능하다.
ap가 주기적으로 비컨 프레임을 노드들에게 전송한다. 와이파이를 켰을때 비컨 프레임을 받기 시작한다. 주변 여러 채널을 왔다갔다 하면서 비컨 프레임을 받는다. 비컨 프레임은 주기적으로 전송된다.
비컨 프레임에는 슈퍼 프레임의 시작지점과 길이가 얼마이고 contention free period가 얼마이다와 같은 내용들이 기록 되어 있다.
contention free period동안 PCF가 동작하는 것이고 다른 contention period동안은 DCF로 동작된다.
contention free period의 길이가 기록 되어 있으므로 스테이션들은 비컨프레임을 받고나서 NAV를 설정한다.
-> 불필요한 캐리어 센싱을 막는 역할
ap의 지시에 의해서만 동작을 하면 된다. ap는 자신의 네트워크에 참여한 노드들에게 돌아가면서 프레임을 전송한다.
1번 노드에게 프레임을 전송한다. D는 downlink라는 의미이다. ap가 station에게 보낸다는 의미이다.
1.PIFS동안 기다리고 ap가 다운링크로 프레임을 노드에게 전송한다.
2. 특정 노드가 업링크로 ap에게 보낼 데이터가 있으면 SIFS만큼 기다렸다가 전송한다.
3.ap가 그 다음 노드에게 보낼게 없어도 니차례가 왔다고 알려줘야 한다. 이때는 SIFS동안만 기다린다.PIFS는 맨처음에만
4.2번노드가 ap에게 보낼 데이터가 없다. ap가 특정 노드로부터 응답이 없을때는 PIFS만큼 기다렸다가 다른 노드에게 다시 전송한다.
위의 예에서는 두번째 노드도 업링크로 ap에게 보낼 데이터가 있다고 가정했을때의 그림이다.
만약에 ap가 전송한 비컨 프레임을 받지 못한 노드가 데이터를 전송하려고 한다고 해도 PCF에서는 PIFS,SIFS만 사용하므로 DIFS를 기다려야 하는 다른 DCF 맥프로토콜을 사용하는 노드들은 절대 경쟁에서 이길수가 없다.
contention free period를 예상보다 빨리 끝내고 싶을때 ap가 노드들에게 프레임을 전송한다. 그다음 contention period로 들어간다.
'컴퓨터 공학과 졸업 > 무선 네트워크' 카테고리의 다른 글
Wireless LAN(IEEE 802.11) - 4(802.11b,802.11a) (0) | 2017.12.09 |
---|---|
Wireless LAN(IEEE 802.11) - 3 (0) | 2017.12.09 |
Wireless LAN(IEEE 802.11) - 1 (2) | 2017.12.09 |
Sensor Network - 2 (SMAC-에너지 효율) (0) | 2017.12.09 |
Sensor network - 1 (0) | 2017.12.04 |
- Total
- Today
- Yesterday
- state
- react hooks
- Babel
- props
- promise
- es6
- reflow
- server side rendering
- webpack
- Polyfill
- async
- computed
- atomic design
- hydrate
- return type
- storybook
- useEffect
- javascript
- Next.js
- typescript
- useRef
- type alias
- Action
- reactdom
- rendering scope
- await
- reducer
- design system
- react
- mobx
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |