Protocol Design List

[norangLemon]

디자인 해야 하는 것들을 정리한다

[norangLemon]

upstream

• 구현되어있음

downstream

• based on duty-cycles(Similar to WiFi PSM mechanism)

Beacon

• beacon interval 정해서 서버/클라에 반영
• end-node는 beacon interval마다 깨서 수신
• gateway는 beacon에 pending downstream frames 보내줌
• pending이 있는 end-node는 frame을 받을 때까지 수신 / 다른 노드는 다음 beacon까지 슬립
• Beacon packet 구조 디자인: 채널 수, 채널 번호
• 핸드셰이킹
• 가능하다면 성능 향상

End-node

• Class A 수정
• 최초 join에 OTAA 사용
• 데이터 보낼 수 있어야 함
• Beacon마다 일어나기
• server가 보내려고 하면 받을 수 있기

Server

• Beacon 스케쥴
• downstream data 보내기
• join된 device 관리

Gateway

• Packet Forwarder & Driver/HAL (그냥 그대로 구우면 될 듯?)

[norangLemon]

고려해 봐야 할 것

• 비콘 충돌 → 4.3.1.2의 ACK 참고
• downstream & upstream
  • 채널 분리 불가능 - 스위칭
  • 채널 분리 가능 - 채널 분배

[pps789]

Data stream control

• Data는 confirmed/unconfirmed 두 종류가 있음
  • confirmed는 ACK를 요구한다.
• upstream: confirmed data 보내고 receive time에서 ACK를 받음
  • 즉 서버는 confirmed data를 받으면 ACK를 보내야 한다.
• downstream: 클라에서 먼저 unconfirmed data를 보내고, 서버가 그걸 보고 confirmed data를 보낸다. 역시 클라는 ACK를 보내야 함.
  • 서버가 원할 때 데이터를 보낼 수는 없고, 결국 클라의 unconfirmed data로 시작해야.

[pps789]

발표해야 할 것

• Beacon에 들어가야 할 것들
• Beacon Timing
• Beacon 채널은 어떻게?
• Downstream ACK control

[pps789]

발표하면 좋은 것

• PSM (Power Save Mode) of Wi-fi
• LoRaWan Class B

[norangLemon]

gateway 스펙 조사 → 다중 송수신 가능한지 살펴보기

[pps789]

Beacon Timing

• Sync: OTAA Join할 때 Beacon 하나 기다려 보기
• 중간에 만약 Beacon이 Delay되어 클라가 못 들었다면?
  • Beacon이 Delay를 복구할 것이라고 기대하고 몇 번 다시 주기를 기다려 보는 게 낫나?
  • 아니면 보수적으로 다음 Beacon이 올 때까지 기다리는게 낫나?

[pps789]

Beacon에 들어가야 할 것들

• 패킷 길이는 어디에 있더라(?)
• Timestamp: 필요없을듯?
• Beacon Interval: 잘 이용하면 성능 개선을 할 수 있지 않을까?
• TargetID: 깨어있으라고 할 클라이언트 ID. 한개? 여러개?

[pps789]

Beacon Principles

• PSM은 서버가 바쁘면 beacon을 안 보낸다. 클라의 Transmit을 막을 순 없으니 / 보내고 있는 걸 끊을 순 없으니 똑같이 해야 할 듯.
• Beacon Interval은 어느 정도가 좋으려나...