급하게 일주일 스터디 하고 만든 프리젠테이션 자료이기 때문에, security 부분과 Link Layer control protocol 부분이 많이 생략되어 있거나 누락되어 있습니다.

1. BLUETOOTH LE CONTROLLER
steveyoon77@gmail.com
윤경록

2. ARCHITECTURE

3. PHYSICAL LAYER

4. PHYSICAL LAYER
BLE는 frequency hopping spread spectrum이라고 부르는 기술을 이용하는데, 이
기술에서 radio는 각 연결 이벤트에서 채널들 사이를 다음의 식을 이용하여 뛰어
다닌다.
channel=(curr_channel+hop) mod 37
여기에서 hop은 매번 새로운 연결이 구축될 때마다 다른 값으로 통신 된다. 이럼
으로써 WiFi와 이전 버전의 Bluetooth와 같이 2.4GHz 밴드를 사용하는 radio의 방
해를 효과적으로 최소화 할 수 있다.
변조 기술로는 다른 저전력 무선 통신에서와 같이 Gaussian Frequency Shift
Keying(GFSK)을 사용하기 때문에 전송 속도가 1Mbit/s로 제한되게 되었다. 그러
나 실제로는 프로토콜 스택에 의한 오버헤드로 application에서 얻어지는
throughput은 훨씬 적어진다.

5. PHYSICAL LAYER
Link Layer의 channels와Wi-Fi channel 간에 위의 그림과 같이 공존할 수 있도록 구성되어 있어서 advertising
channel이 Wi-Fi에 의해 방해 받지 않을 수 있다.

6. LINK LAYER
Link layer는 복잡한 프로토콜을 감추고 실시간 성을 유지하기 위해 하드웨어 벤
더가 쉽게 구현할 수 있는 부분을 독립 시킨 계층이다.
이 계층은 다음과 같은 기능들을 포함한다.
 Preamble, Access Address, and Air Protocol Framing
 CRC generation and verification
 Data whitening
 Random number generation
 AES encryption

7. LINK LAYER
Link Layer는 다음과 같은 역할들을 정의하고 있다.
 Advertiser: A device sending advertising packets
 Scanner: A device scanning for advertising packets
 Master: A device that initiates a connection and manages it later
 Slave: A device that accepts a connection request and follows the master's timing

8. BIT STREAM PROCESSING
frequency shift keying 알고리즘은 같은 값의 비트 시퀀스가 매우 길면 문제가 생긴다.
예를 들어 0000000b나 1111111b와 같은 비트 스트림이 송신 되면 수신기는 송신기의 center frequency가
왼쪽으로 이동 되었다고 가정을 하고 이것은 frequency lock을 놓쳤다고 판단하는 결과를 초래해서
(frequency shift하여 다시 lock을 했을 때) 다음 1비트를 잃어버리게 된다.
그래서 Data whitening(7-bit linear feedback shift register, polynomial x^7+x^4+1)을 통해 같은 값으로
반복되는 스트림을 제거해준다.

9. LINK LAYER DEVICE FILTERING
White List
 White List는 device address와 device address type(public or random)을 저장한다.
 디바이스를 껐다 켜면(reset) white list는 지워진다.
 호스트에 의해 설정된다
 이 설정으로 연결 어떤 연결과 관련된 요청에 호스트를 깨우지 않고 Link Layer
가 동작될 수 있다.

10. LINK LAYER DEVICE FILTERING
Advertising Filter Policy
Link Layer가 Connectable Directed Advertising을 이용하고 있을 때, advertising filter policy는 무시된다.
그렇지 않다면 다음과 같이 호스트의 설정에 의해 advertising filter policy mode들을 따라야 한다.
 white list에 있는 디바이스의 Scan, Connection 요청만 처리한다.
 white list를 쓰지 않는다면(reset 직후) 모든 디바이스의 scan, connection 요청을 처리해야 한다.
 모든 디바이스의 scan 요청을 처리하고 white list에 있는 디바이스의 connection 요청만 처리해야 한다.
 모든 디바이스의 connection 요청을 처리하고 white list에 있는 디바이스의 scan 요청만 처리해야 한다.
 한 번에 오직 하나의 advertising filter policy만 적용 될 수 있다.

11. LINK LAYER DEVICE FILTERING
Scanner Filter Policy
 white list에 있는 디바이스로부터 온 advertising packet만 처리해야 한다. scanner의 device
address가 없는 connectable Directed advertising packet은 무시해야 한다.
 white list를 쓰지 않는다면(reset 직후) 모든 디바이스의 advertising packet을 처리해야 한다.
scanner의 device address가 없는 connectable Directed advertising packet은 무시해야 한다.
Link Layer가 Extended Scanner Filter policy들을 지원한다면 다음의 mode들도 지원해야 한다.
 white list에 있는 디바이스로부터 온 advertising packet만 처리해야 한다. Connectable Directed
advertising packet의 Initiator Device Address가 Resolvable Private Address라면 무시하지 말아야
한다.
 white list를 쓰지 않는다면(reset 직후) 모든 디바이스의 advertising packet을 처리해야 한다.
Connectable Directed advertising packet의 Initiator Device Address가 Resolvable Private
Address라면 무시하지 말아야 한다.
 한 번에 오직 하나의 scanner filter policy만 적용될 수 있다.

12. LINK LAYER DEVICE FILTERING
Initiator Filter Policy
 white list에 있는 디바이스로부터 온 connectable advertising packet은 모두 처
리해야 한다.
 호스트에 의해 정의된 특정한 디바이스로부터 온 connectable advertising
packet은 white list에 관계없이 처리되어야 한다.
 한 번에 오직 하나의 initiator filter policy만 적용될 수 있다.

13. STATE MACHINE

14. STANDBY STATE
Link Layers에 전원이 들어가면 Standby State에서 시작하고, Host layers가 무얼
시킬 때까지 계속 그 상태에 머무른다.
다른 모든 상태에서 돌아올 수 있는 Standby State는 아무 일도 하지 않지만 매우
중요한 상태이다.

15. ADVERTISING STATE
Link Layer가 advertising packet을 전송할 수 있도록 한다.
또, Scan Request에 대하여 Scan Response로 응답할 수 있다.
디바이스가 Discoverable 하거나 Connectable 하기를 원한다면 이 상태여야 한다.
그리고 디바이스가 다른 디바이스들에게 데이터를 broadcast 하기 위해서도 이
상태여야 한다.
이 상태가 되기 위해서, 디바이스는 송신기를 달고 있어야 한다. 수신기도 함께
가지고 있어도 된다.
Advertising을 멈춤으로써 Standby State로 돌아갈 수 있고, Initiate State에 있던
디바이스의 Connect Request를 받으면 Connect State로 갈 수도 있다

16. ADVERTISING STATE
Advertising event는 다음의 타입 중 하나이다.
Advertising EventType Related PDU Allowable response PDU
SCAN_REQ CONNECT_REQ
Connectable Unidirected Event ADV_IND Yes Yes
Connectable Directed Event ADV_DIRECT_IND No Yes
Non-connectable Undirected Event ADV_NONCONN_IND No No
Scannable Undirected Event ADV_SCAN_IND Yes No

17. ADVERTISING STATE
Advertising Interval
T_advEvent = advInterval + advDelay
 advInterval은 20ms부터 10.24s 까지의 범위에서 0.625ms의 배수로 정의 된다.
 advertising event type이 scannable undirected event이거나 non-connectable undirected
event이면, advInterval은 100ms보다 작아야 한다.
 advertising event type이 connectable undirected event이거나 low duty cycle mode의
connectable directed event이면, advInterval은 20ms 이상일 수 있다.
 advDelay는 각 advertising event마다 생성되는 0ms부터 10ms 사이의 pseudo-random
값이다.

18. ADVERTISING STATE
Advertising Interval

19. ADVERTISING STATE
Connectable Undirected Event Type
 connectable undirected advertising event(ADV_IND)는 scanner와 initiator에게 scan
request(SCAN_REQ)나 connect request(CONNECT_REQ)를 응답하게 한다.
 Advertiser가 SCAN_REQ를 받았을 때, SCAN_REQ를 보낸 scanner가 advertising filter policy에 적
합하다면 SCAN_REQ를 받은 것과 같은 advertising channel로 SCAN_RSP를 보낸다.
 SCAN_RSP를 보냈거나, SCAN_REQ를 보낸 scanner가 advertising filter policy에 부적합했다면 다
음 advertising channel을 사용하여 ADV_IND를 보내거나 advertising event를 끝낸다.
 Advertiser가 CONNECT_REQ를 받았을 때, CONNECT_REQ를 보낸 initiator가 advertising filter
policy에 적합하다면 State를 connection State로 전환하고 Slave 역할을 수행한다.
 CONNECT_REQ를 보낸 initiator가 advertising filter policy에 부적합했다면 다음 advertising
channel을 사용하여 ADV_IND를 보내거나 advertising event를 끝낸다.

20. ADVERTISING STATE
Connectable undirected advertising event(ADV_IND)의 타이밍은 다음 그림과 같다.
ADV_IND만 있는 경우

21. ADVERTISING STATE
Connectable undirected advertising event(ADV_IND)의 타이밍은 다음 그림과 같다.
ADV_IND의 응답이 있는 경우

22. ADVERTISING STATE
Connectable undirected advertising event(ADV_IND)의 타이밍은 다음 그림과 같다.
ADV_IND의 응답이 있는 경우

23. ADVERTISING STATE
Connectable undirected advertising event(ADV_IND)의 타이밍은 다음 그림과 같다.
ADV_IND의 응답이 있는 경우

24. ADVERTISING STATE
Connectable Directed Event Type
 connectable directed event(ADV_DIRECT_IND)는 ADV_DIRECT_IND에서 지시된
device address의 initiator에게 connection request(CONNECT_REQ)를 응답하게 한
다.
 ADV_DIRECT_IND를 보낸 advertiser는 같은 advertising channel로 CONNECT_REQ
만 기다리고, SCAN_REQ는 무시한다.
 이 advertiser가 CONNECT_REQ를 받으면 State를 Connection State로 바꾸고
Slave 역할을 수행한다.
 그렇지 않다면 다음 advertising channel로 가서 ADV_DIRECT_IND를 보내거나
advertising event를 끝낸다.

25. ADVERTISING STATE
Low Duty Cycle Directed Advertising

26. ADVERTISING STATE
Low Duty Cycle Directed Advertising

27. ADVERTISING STATE
High Duty Cycle Directed Advertising

28. ADVERTISING STATE
Scannable Undirected Event Type
 scannable undirected event(ADV_SCAN_IND)는 scanner에게 추가적인 정
보를 advertiser에게서 얻기 위해 scan requenst(SCAN_REQ)를 보내게 한다.
 ADV_SCAN_IND를 보낸 advertiser는 ADV_SCAN_IND를 보낸 advertising
channel에서 SCAN_REQ를 기다린다.
 SCAN_REQ를 보낸 scanner의 device address가 advertising filter policy에
적합하다면 SCAN_RSP를 보낸다.
 SCAN_RSP를 보냈거나 SCAN_REQ를 보낸 scanner의 device address가
advertising filter policy에 부적합했다면 다음 advertising channel에서
ADV_SCAN_IND를 보내거나 advertising event를 끝낸다.

29. ADVERTISING STATE
ADV_SCAN_IND를 보내는 타이밍은 아래의 그림과 같다.

30. ADVERTISING STATE
ADV_SCAN_IND에 대한 응답으로 SCAN_REQ를 받고 SCAN_RSP를 다시 보낼 때의 타이밍은
아래의 그림과 같다.

31. ADVERTISING STATE
ADV_SCAN_IND에 대한 응답으로 SCAN_REQ를 받고 SCAN_RSP를 다시 보낼 때의 타이밍은
아래의 그림과 같다.

32. ADVERTISING STATE
Non-connectable Unidirected EventType
Non-connectable Undirected Event를 Broadcasting이라고 부르고 데이터를 방송하는데 사용된다.

33. ADVERTISING STATE
Non-connectable Unidirected EventType
Non-connectable Undirected Event를 Broadcasting이라고 부르고 데이터를 방송하는데 사용된다.

34. ADVERTISING STATE
Advertising and scanning
advertising은 20ms에서 10.24s 마다 전송되는 rate을 가질 수 있는데, 전송 rate이 빠르면
빠를 수록 전력 소모가 커진다.

35. SCANNING STATE
이 상태의 디바이스는 Advertising Channel packet을 받을 수 있다.
Scanning State는 다음과 같은 하부 상태가 있다.
 Passive scanning: scanner는 단순히 advertising packets를 듣기만 하고,
advertiser는 몇 개의 packet을 scanner가 받았는지 절대 알지 못한다.
 Active scanning: scanner가 advertising packet을 받은 뒤에 Scan Request packet
을 보낸다. 이걸 advertiser가 받은 뒤 Scan Response packet으로 응답한다. 그러
나 이것이 사용자 데이터를 scanner가 모든 advertiser에게 보낸다는 것을 의미
하는 것은 아니다. Scan response를 보낸 뒤 Standby 상태로 돌아간다.

36. SCANNING STATE

37. SCANNING STATE
Passive Scanning
Advertiser로부터 packet을 받기만 하므로 broadcasting data를 획득하기 위해 이용된다고 볼
수 있다.

38. SCANNING STATE
Active Scanning
• SCAN_REQ는 ADV_DIRECT_IND와 ADV_NONCONN_IND에 대해서는 보내지지 않는다.
• advertiser의 device address가 scanner filter policy에 적합하고 ADV_IND나
ADV_SCAN_IND를 보냈을 경우 SCAN_REQ를 보낸다.
• SCAN_REQ는 SCAN_RES를 받을 때까지 해당하는 advertiser에게 계속 보낸다.
• SCAN_REQ 충돌(collision)을 최소화 하기 위해 철회(backoff) 절차를 수행해야 한다.
• 철회(backoff) 절차에서는 SCAN_REQ의 수를 제한하기 위해 backoffCount와 upperLinit
파라미터를 쓴다.
• Scanning 상태가 되면 upponLimit과 backoffCount는 각각 1로 설정된다.
• ADV_IND나 ADV_SCAN_IND를 받아서 SCAN_REQ를 보내게 되면 backoffCount는 0이 될
때까지 1씩 감소시킨다. SCAN_REQ는 backoffCount가 0이 될 때 까지 계속 보낸다.
• SCAN_REQ에 대하여 SCAN_RES를 받으면 성공, 못 받으면 실패인데, 두 번 연속해서
실패하면 최대 256값이 될 때까지 upperLimit을 두 배씩 증가시킨다. 두 번 연속해서
성공하면 최소 1이 될 때까지 절반씩 감소시킨다.
• SCAN_RSP를 받는 게 성공하건 실패하건, backoffCount는 1부터 upperLimit 값 사이의
pseudo-random 정수로 셋팅 한다.

39. INITIATING STATE
 다른 디바이스에 연결되려고 초기화 할 때 위치 되는 상태이다.
 디바이스가 이 상태에 있다가 연결하려고 하는 디바이스의 advertising
packet(ADV_IND, ADV_DIRECT_IND)을 받으면 Connect Request를 보내고
Connection State(Master)로 전환된다.
 이 때 advertising packet을 보낸 디바이스는 함께 Connection State(Slave)로 전
환된다.

40. CONNECTION STATE
Initiating State에 있던 디바이스와 Advertising State에 있던 디바이스가 Connect Request를 주고 받은 뒤 위치
하는 상태이다. 이 상태에도 다음과 같은 하부 상태가 있다.
 Master: Master 역할을 가진 디바이스는 Initiating State에 있었다. 규칙적으로 Slave에 메시지를 보내야 한다.
이 메시지의 응답으로 Slave가 자기의 데이터를 Master에 보낼 수 있다.
 Slave: Slave 역할을 가진 디바이스는 Advertising State에 있었다. Master가 메시지를 보내야만 응답으로 자신
의 데이터를 보낼 수 있는데, 가끔 Master의 메시지를 무시함으로써 전력을 아낄 수도 있다.
Connection은 Creating와 Establishing의 단계로 이루어진다.
Creating 단계는 Initiator와 Advertiser가 서로 교통하여 Connection State에 들어서는 단계이고, Establish 단계는
첫 번째 Data Packet을 받았을 때부터 Establish 단계라고 한다. Establish 된 Connection에서는 Supervision
timeout(TLLconnSuperVision)을 사용하는데, Supervision timeout은 연결이 끊어지기 전 Data Packet 두 개를 받는 최
대 시간으로, 10ms의 배수이며, 100ms ~ 32.0s 사이의 값을 갖고, (1 + connSlaveLatency) * connInterval * 2보
다 커야만 한다.
Connection 상태에서는 오직 Data channel만 사용되고, 다른 상태에서는 advertising channel을 사용한다.

41. CONNECTION STATE

42. CONNECTION STATE
Connection Setup - Master Role
Master에서 바라본 transmitWindowOffset이 0이 아닐 때 LL connection setup

43. CONNECTION STATE
Connection Setup - Master Role
Master에서 바라본 transmitWindowOffset이 0일 때 LL connection setup

44. CONNECTION STATE
Connection Setup - Slave Role
첫 번째 패킷을 받으면 CRC가 틀리더라도 Access Address가 맞는다면 Connection Event를
시작하는 anchor point를 결정한다. 첫 번째 패킷을 받지 못하면 connInterval 뒤에 이어지는
Transmit Window 동안 Master의 Data Packet을 받기를 기다린다. 아래의 그림은 첫 번째 패킷을
받는 시도(connEventCount=0)가 실패한 뒤 두 번째 패킷을 받는 시도(connEventCount=1)가
성공하여 그 때 Connection의 Anchor point를 결정하는 그림이다.

45. CONNECTION STATE
Closing Connection Event
• Master와 Slave가 주고 받아야 할 데이터가 더 이상 없거나,
• 연속해서 CRC가 깨지면 연결을 종료한다.
Window Widening
Sleep Clock Accuracy들 때문에 Slave가 정확한 Master의 anchor point를 놓칠 수 있다. 그래서
CRC의 매칭 여부와 관계없이 Master의 Packet을 받으면 Slave는 anchor point를 업데이트
해야만 한다.
이 업데이트로 증가된 listening time을 window widening이라고 한다. window widening은
다음과 같이 구할 수 있다.
• windowWidening = ((masterSCA + slaveSCA) / 1000000) * timeSinceLastAnchor
• windowWidening < ((connInterval / 2) - T_IFS us)

46. CONNECTION STATE
Data Channel Index Selection
먼저 아래의 식으로 channel index를 구하고,
unmappedChannel = (lastUnmappedChannel + hopIncrement) mod 37
이 channel index가 channel map에서 unused로 설정되어 있다면 아래의 식으로 다시 구한다.
remappingIndex = unmappedChannel mod numUsedChannels
여기에서 numUsedChannel은 channel map에 used로 설정되어있는 채널의 수이다.

47. CONNECTION STATE
Acknowledgement and Flow Control
• Master가 연속된 데이터의 첫 패킷(Connection Event)을 보냈다.
• Slave가 다음 시퀀스 넘버를 증가 시켜서 응답 패킷을 보냈으나
Master가 받지를 못했다.
• Master가 Slave가 아까 보낸 패킷을 다시 전송했다.
• Slave가 다시 한 번 시퀀스 넘버를 증가 시켜서 응답 패킷을 보냈다.
이번엔 받았다.
• Master가 연속된 데이터의 마지막 패킷을 보냈다.
• Slave가 다음 시퀀스 넘버를 증가 시켜서 응답 패킷을 보냈다.
이번에도 받았고, 더 이상 보낼 패킷이 없으므로 End Connection
Event.
• Next Connection Event로 Master가 단일 데이터 패킷을 보냈다.
• Slave가 다음 시퀀스 넘버를 증가 시켜서 응답 패킷을 보냈다. 더
이상 Master가 보낼 패킷이 없으므로 End Connection Event.

48. MULTIPLE STATE MACHINES

49. DEVICE ADDRESS
Device address는 48비트로 이루어져 있다.
device_address {
bit address[48];
};

50. DEVICE ADDRESS
이 address를 전달하는 PDU의 헤더에 의해 지시되는 address의 type은 두 가지로,
public address이거나 random address이다.
// determination between public or random address
if (type_flag==0) {
address = { // public IEEE 802-2001 MAC address
u8 companny_id[3];
u8 command_assigned[3];
};
} else if (type_flag==1) {
address = {
bit flag[2];
bit random_device_address[46];
};
}

51. DEVICE ADDRESS
random_address는 다음과 같이 다시 3가지의 형식으로 구분된다.
// determination between static or private random address
if (flag == '00b') {
random_device_address = {
// random part of non-resolvable address
bit nonresolvable_address[46];
};
} else if (flag == '01b') {
random_device_address = {
bit prand[22]; // random part of prand
bit hash[24]; // hash=ah(IRK, prand)
};
} else if (flag == '11b') {
random_device_address = {
// random part of static address
bit static_address[46];
};
}

52. DEVICE ADDRESS
static_address는 전원이 켜질 때 처음 만들어져서 전원이 꺼질 때까지 유지되는 정적인 address로,
만약에 연결되었던 디바이스 중 하나의 전원이 꺼졌다가 켜져서 그 디바이스의 static_address가
바뀐다면 이전의 연결은 더 이상 유효하지 않게 된다.
나머지 두 개의 device address를 private address라고 부르는데, 각각은 다시 non-resolvable private
address, resolvable private address로 부른다.
non-resolvable address는 random address로 모든 비트가 0으로 되어 있거나 1로 되어 있어서는
안되고 public address와 동일하지 않기만 하면 된다.
resolvable address는 prand 부분과 hash 부분으로 이루어져 있다. 다만 prand 부분은 MSB로,
hash는 LSB로 구성하여 concatenating(결합) 한다.

53. PACKET
BLE는 오직 하나의 패킷 형식과 두 타입의 패킷 만을 가지고 있다. 두 타입은 패킷은 advertising
packet과 data packet이다.
패킷 형식은 다음과 같다.
packet {
u8 crc[3];
u8 payload[length];
u8 length;
u8 header;
u8 access_address[4];
u8 preamble;
}

54. PACKET
Preamble
• Preamble은 0101010이나 10101010이다.
• Access address의 첫 비트가 0이면 01010101 시퀀스가 이용되고,
• access address의 첫 비트가 1이면 10101010 시퀀스가 이용된다.
• 이것은 패킷의 첫 9비트가 101010101이든 010101010이든 항상 교차 비트(alternating bit)가 된다는
것이다.
• 이것으로 입력 신호 세기를 판단하여 auto gain control에 이용할 수 있다.
Access Address
• Advertising access address: 0x8E89BED6(01101011011111011001000101110001b)
• Data access address
• 0이나 1이 6개 이상 연속되지 않아야 한다.
• advertising channel packet의 access address가 아니어야 한다.
• 적어도 한 비트 이상 advertising access address와 달라야 한다.
• 각 8비트들은 반복된 패턴(같은 값)이면 안 된다.
• alternating bit sequence의 사용을 멈추기 때문에 24번 이상의 비트 전환이 있어서는 안 된다.
• 마지막 여섯 비트 중에 적어도 두 번의 비트 전환이 있어야만 한다.
• 위 조건들에 따라 약 231 개의 random access address가 가능하다.
• 이런 random access address 때문에 공격자가 연결 중인 두 개의 디바이스를 이 주소를 수신하는 것
만으로 특정 지을 수 없어서 연결 기간 동안 디바이스의 프라이버시를 보장하는 기능도 있다.

55. PACKET
Header
header는 packet의 종류에 따라 advertising header와 data header로 구분된다.
Length
payload의 길이를 octet 값으로 표현한다.
• Advertising Packet Length
• 6 bits로 구성
• 6 ~ 37의 값
• Data packet Length
• 8 bits로 구성
• 0 ~ 255의 값
Cyclic Redundancy Check
• header, length, payload field를 계산한다.
• noisy 한 환경이므로 16-bit CRC는 신뢰성이 떨어지고,
• 32-bit CRC는 BLE에서 전송할 수 있는 데이터 크기 중 6 비트 데이터의 에러를 검증할 수 없다.

56. ADVERTISING PACKET
advertising_packet {
u8 crc[3];
u8 payload[length]; // 6~37 octets
u8 length;
u8 header;
u8 access_address[4];
u8 preamble;
}
Advertising packet은 다음과 같은 목적에 이용된다.
• 완전한 연결 구축의 오버헤드를 필요로 하지 않는 어플리케이션을 위해 데이터를 방송하기
위해,
• Slave를 발견할 수 있게 하고, 그 Slave에 연결할 수 있게 하기 위해 (여기에서 Slave는 아직
Advertiser임)

57. ADVERTISING PACKET HEADER
advertising_packet_header {
bit rx_add;
bit tx_add;
bit rfu[2]; // reserved for future
bit advertising_packet_type[4];
}
Advertising Packet Type
Packet Name Value Description
ADV_IND 0000b General advertising indication
ADV_DIRECT_IND 0001b Direct connection indication
ADV_NONCONN_IND 0010b Nonconnectable indication
SCAN_REQ 0011b Active scanning request
SCAN_RSP 0100b Active scanning response
CONNECT_REQ 0101b Connection request
ADV_SCAN_IND 0110b Scannable indication
Reserved 0111b~1111b Reserved for future
tx_add, rx_add
tx_add, rx_add 필드들은 Advertising Packet
Type에 따라 정의되는데, 만약 주어진 Type에
따라 정의되어 있지 않다면 나중을 위해
예약된 필드로 본다.

58. ADVERTISING PDUS
Advertising PDUs은 다음과 같은 이벤트에서 사용되는 PDUs을 말한다.
PDU Description Example
ADV_IND connectable undirected advertising event “Hello, I'm Steve ”
ADV_DIRECT_IND connectable directed advertising event “Hello Robin, I'm Steve”
ADV_NONCONN_IND non-connectable undirected advertising event “Hello, I'm Steve”
ADV_SCAN_IND scannable undirected advertising event “Hello, I'm Steve”

59. ADV_IND
payload {
u8 advertising_data[]; // size of data is 0 to 31 octets
bit advertiser_address[48];
}
이 PDU에서 advertiser의 device address가 public이면 advertising header의 tx_add는 0,
random이면 tx_add는 1이다.

60. ADV_DIRECT_IND
이 PDU에서 advertiser_address가 public이면 advertising header의 tx_add는 0, random이면
tx_add는 1이고, initiator_address가 public이면 rx_add는 0, random이면 rx_add는 1이다.
payload {
bit initator_address[48];
bit advertiser_address[48];
}

61. ADV_NONCONN_IND
이 PDU도 마찬가지로 advertiser_address가 public이면 advertising header의 tx_add는 0,
random이면 tx_add는 1이다.
payload {
u8 advertising_data[]; // size of data is 0 to 31 octets
bit advertiser_address[48];
}

62. ADV_SCAN_IND
이 PDU도 또한 advertiser_address가 public이면 advertising header의 tx_add는 0, random이면
tx_add는 1이다.
payload {
u8 advertising_data[]; // size of data is 0 to 31 octets
bit advertising_address[48];
}

63. SCANNING PDUS
다음과 같은 PDUs을 scanning PDUs라고 부른다.
PDU Description Example
SCAN_REQ scanner가 보내고 advertiser가 받는다. “Hello Steve, I'm Robin. Could you please
give me your information?”
SCAN_RES advertiser가 보내고 scanner가 받는다. “Hello Robin, I'm Steve.This is my resume,
Mom wrote for me.”

64. SCAN_REQ
scanner_address가 public이면 advertising header의 tx_add가 0, random이면 tx_add가 1이고,
advertiser_address가 public이면 header의 rx_add가 0, random이면 x_add가 1이다.
payload {
bit advertiser_address[48];
bit scanner_address[48];
}

65. SCAN_RSP
advertiser_address가 public이면 advertising header의 tx_add가 0, random이면 tx_add가
1이다.
payload {
u8 scan_response_data[]; // size of data is 0 to 31
bit advertiser_address[48];
}

66. INITIATING PDU - CONNECT_REQ
payload의 initiator_address가 public이면
header의 tx_add는 0, random이면 tx_add는
1이고,
advertiser_address가 public이면 header의
rx_add는 0이고 random이면 rx_add는 1이다.
payload {
u8 link_layer_data[22];
bit advertiser_address[48];
bit initiator_address[48];
}
link_layer_data {
bit sleep_clock_accuracy[3];
bit hop[5];
u8 channel_map[5];
u8 timeout[2];
u8 latency[2];
u8 interval[2];
u8 window_offset[2];
u8 window_size;
u8 crc_init[3];
u8 access_address[4];
}

67. INITIATING PDU - CONNECT_REQ
link_layer_data의 각 필드는 다음과 같다.
Field Symbol Description
access_address AA Link Layer의 access address.
crc_init CRCInit Link Layer 연결을 위한 CRC 계산의 초기값.
window_size WinSize transmitWindowSize를 구하기 위한 값. transmitWindowSize = window_size * 1.25 ms
window_offset WinOffset transmitWindowOffset을 구하기 위한 값. transmitWindowOffset=window_offset * 1.25 ms
interval Interval connInterval을 구하기 위한 값. connInterval=interval * 1.25 ms
latency Latency connSlaveLatency를 구하기 위한 값. connSlaveLatency = latency
timeout Timeout connSupervisionTimeout을 구하기 위한 값. connSupervisionTimeout =Timeout * 10ms
channel_map ChM 사용되고 사용되지 않는 채널을 가리킨다. LSB로 표현되고 37th, 38th, and 39th bit position
은 예약되어(RFU) 있다.
hop Hop hopIncrement를 구하기 위한 값. 5~16의 범위에 있는 랜덤 값.
sleep_clock_accuracy SCA 가장 나쁜 경우의 Master sleep clock accuracy를 결정하기 위해 사용되는masterSCA를 구
하기 위한 값.

68. INITIATING PDU - CONNECT_REQ
masterSCA는 다음과 같이 결정할 수 있다.
SCA masterSCA
0 251 ppm ~ 500 ppm
1 151 ppm ~ 250 ppm
2 101 ppm ~ 150 ppm
3 76 ppm ~ 100 ppm
4 51 ppm ~ 75 ppm
5 31 ppm ~ 50 ppm
6 21 ppm ~ 30 ppm
7 0 ppm ~ 20 ppm

69. DATA PACKET
data_packet {
u8 crc[3];
u8 mic[4]; // optional
u8 payload[length]; // 0~251 octets, if mic is present.
u8 length;
u8 header;
u8 access_address[4];
u8 preamble;
}
MIC(Message Integrity Check)
• 암호화 되지 않은 Link Layer 연결에서는 mic field가 필요 없고, 이 경우에는 payload의 크기는
0 ~ 255 octets만큼 가질 수 있다.
• 암호화 된 Link Layer 연결에서 Payload의 크기가 0인 경우에도 mic field가 필요 없다.
• MIC는 AES-128 CCM mode를 사용하여 계산한다.

70. DATA PACKET HEADER
data_packet_header {
bit rfu[3];
bit more_data;
bit sequence_no;
bit next_sequence_no;
bit link_layer_identifier[2];
}

71. DATA PACKET HEADER
link_layer_identifier
Value Description
01b 상위 계층 패킷의 연속
10b 상위 계층 패킷의 시작이거나 완료 패킷
11b Link Layer 제어 패킷, 연결 관리에 사용된다

72. LL DATA PDU
• LL Data PDU는 L2CAP data를 보내는데 이용되는 data channel PDU이다.
• LLID 필드는 01b나 10b로 셋팅 되어야 한다.
• LLID 필드가 01b로 셋팅 되어 있고, Length가 0인 PDU를 empty PDU라고 부른다.
• LLID 필드가 10b로 셋팅 되어 있으면 Length가 0인 PDU를 보낼 수 없다.

73. LL CONTROL PDU
payload {
/* size of control_data is 0 to 26 octets
* as defined by opcode
*/
u8 control_data[];
u8 opcode;
}
Opcode Control PDU name From
0x00 LL_CONNECTION_UPDATE_REQ Master
0x01 LL_CHANNEL_MAP_REQ Master
0x02 LL_TERMINATE_IND Master/Slave
0x03 LL_ENC_REQ Master
0x04 LL_ENC_RSP Slave
0x05 LL_ENC_START_ENC_REQ Slave
0x06 LL_ENC_START_ENC_RES Master/Slave
0x07 LL_UNKNOWN_RSP
0x08 LL_FEATURE_REQ Master
0x09 LL_FEATURE_RSP Slave
0x0A LL_PAUSE_ENC_REQ Master
0x0B LL_PAUSE_ENC_RSP Master/Slave
0x0C LL_VERSION_IND Master/Slave
0x0D LL_REJECT_IND
0x0E LL_SLAVE_FEATURE_REQ
0x0F LL_CONNECTION_PARAM_REQ Master/Slave
0x10 LL_CONNECTION_PARAM_RSP Slave
0x11 LL_REJECT_IND_EXT
0x12 LL_PING_REQ Master/Slave
0x13 LL_PING_RSP Master/Slave
0x14 LL_LENGTH_REQ Master/Slave
0x15 LL_LENGTH_RSP Master/Slave
0x16 ~ 0xFF Reserved for future use

74. REFERENCES
정리:
http://steveyoon77.kr/dokuwiki/
doku.php?id=bluetooth