{"id":202,"date":"2020-10-29T14:48:25","date_gmt":"2020-10-29T18:48:25","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/iotbook\/?post_type=back-matter&p=202"},"modified":"2020-11-15T16:17:13","modified_gmt":"2020-11-15T21:17:13","slug":"appendix-a","status":"publish","type":"back-matter","link":"https:\/\/pressbooks.bccampus.ca\/iotbook\/back-matter\/appendix-a\/","title":{"raw":"Appendix A","rendered":"Appendix A"},"content":{"raw":"
\r\n

\u00a0 In BLE terminology, scan interval (T<\/span>) is the duration of time between two consecutive times that the scanner wakes up to receive the advertising messages. The scan interval is shown in Figure A.1. When the scanner wakes up, it enables its reception to be able to listen to the advertising messages for a duration of TS<\/sub><\/span>, which is called the scan window. The value of scan interval should always be greater than or equal to the scan window. The values of T\u00a0<\/span>and TS <\/sub><\/span>should always be in the range of\u00a0 \u00a00 \u2264 TS<\/sub>\u2264 T\u2264 10.24 s. In general, BLE modules use three different channels for advertising which are called Channel 37, 38 and 39. When a BLE module becomes a scanner or initiator, it scans these three advertising channels one by one in sequence of Channel 37, 38, and 39, according to a round-robin fashion, as shown in Figure A.1.<\/p>\r\n \r\n\r\n[caption id=\"attachment_267\" align=\"aligncenter\" width=\"573\"]\"\" Figure A.1: BLE scanning\/ initiating process[\/caption]\r\n

The advertiser periodically generates advertising events. Each advertising event consists of a sequence of advertising messages. Tad <\/sub><\/span>is the duration of time that will take for the advertiser to send an advertising message on a predefined advertising channel during each advertising event. At that time, the advertiser goes into the reception mode and listens for the duration of Tr <\/sub><\/span>on the same channel. Then, as shown in Figure A.2, the advertiser moves to the next advertising channel.<\/p>\r\n \r\n

<\/p>\r\n\r\n<\/div>\r\n\r\n[caption id=\"attachment_268\" align=\"aligncenter\" width=\"812\"]\"\" Figure A.2: Advertising process[\/caption]\r\n\r\n

\r\n

Two types of scanning are defined for a BLE device which are called passive scanning and active scanning. In passive scanning, a scanner receives advertisement messages, but does not send any packet to the advertiser, while in active scanning, the scanner listens to advertisement messages and after receiving an advertisement message, it sends a scan request packet to the advertiser. The scan request packet can help the scanner to learn more about the advertiser. For example, the scanner can ask about supported services by the advertiser. In response, the advertiser can send a list of its supported services.<\/p>\r\n

The value of Tad <\/sub><\/span>is determined by the size of an advertising message. The size of each advertising message can be as small as 80 bits or as long as 376 bits. The value of Tr<\/sub> is adjusted to the tolerable time for the advertiser to wait for the scanner\u2019s reply. The value of Ta <\/sub><\/span>represents the interval between two advertising events and consists of a fixed interval,\u00a0 Ti<\/sub><\/span>, and a variable interval which can be represented as a pseudorandom delay Trd <\/sub><\/span>. Based on BLE specifications, 20 ms \u2264 Ti<\/sub> \u2264 10.24 s<\/span>, 0 \u2264 Trd<\/sub> \u2264 10 ms<\/span>, and the value of Ti <\/sub><\/span>should be a multiple of 0.625 ms<\/span>.<\/p>\r\n

Since there is possibility of receiving several scan request messages <\/span>from<\/span> an advertiser by multiple scanners, <\/span>it is likely that the packets collide with each other<\/span>. If such a situation arose, each scanner should use <\/span>a <\/span>back-off strategy to minimize the possibility of collisions. <\/span><\/p>\r\n

After receiving an advertising message by a scanner or initiator, they can initiate a connection. Connections enable a reliable communication for data transmission. To ensure robust delivery of data, Cyclic Redundancy Checks (CRC), acknowledgements, and retransmissions of lost or corrupted data are considered in BLE connections. BLE uses Adaptive Frequency Hopping (AFH) to detect and adapt hopping sequences dynamically to the surrounding environment and provide a robust physical layer. Data encryption is also supported by connections. A connection is initialized when a scanner (central BLE) sends a Connect Request packet. When the advertiser receives a Connect Request message and accepts this request, it stops advertising and follows the parameters in the Connect Request packet to start a connection. An advertiser checks several conditions before accepting the connection request. The advertiser needs to be enabled to accept connections and should not have any whitelist or if it has one, the initiator's address should be in the whitelist. After establishing the connection, the initiator becomes the central node and the advertiser becomes the peripheral node. The central BLE node sends a connection event message on every connection interval. And the peripheral BLE node opens the scan window on every connection interval after the first connection event. The peripheral then sends a connection event packet toward the central node which acts as an acknowledgment. This packet may contain the user data as well.<\/p>\r\n

The connection parameters provide information about the communication between the central and peripheral BLE node and are included in the Connect Request packet. A Connect Request packet contains several fields. The most important fields of this packet are interval, latency, and timeout. Connection Interval (CI) is the time between two BLE connection events. The peripheral BLE node specifies the minimum and maximum values of interval, but the CI value for communication is set by the central node when the BLE connection is first established. Some central BLE devices ignore the maximum and minimum values specified by the peripheral and use some default CI values instead. The duration of CI is equal to the interval times\u00a01.25 ms<\/span>. The BLE specifications state that the interval can be any value between 6 and 3200. In other words, the connection interval time can accept any value in the range of 7.5 ms <\/span>to 4000 ms<\/span>. Latency field defines the number of connection events the peripheral BLE node is allowed to skip the transmission. If the peripheral node does not have any data to send, it has the option to skip several connection events. This can provide some reduction in power consumption for the peripheral device. It should be noted that the peripheral BLE node should not stay too long in the sleep mode to lose its connection to the central BLE node. The number of consecutive connection events that the central BLE node continues its operation without receiving any data is defined as timeout.<\/p>\r\n\r\n<\/div>","rendered":"

\n

\u00a0 In BLE terminology, scan interval (T<\/span>) is the duration of time between two consecutive times that the scanner wakes up to receive the advertising messages. The scan interval is shown in Figure A.1. When the scanner wakes up, it enables its reception to be able to listen to the advertising messages for a duration of TS<\/sub><\/span>, which is called the scan window. The value of scan interval should always be greater than or equal to the scan window. The values of T\u00a0<\/span>and TS <\/sub><\/span>should always be in the range of\u00a0 \u00a00 \u2264 TS<\/sub>\u2264 T\u2264 10.24 s. In general, BLE modules use three different channels for advertising which are called Channel 37, 38 and 39. When a BLE module becomes a scanner or initiator, it scans these three advertising channels one by one in sequence of Channel 37, 38, and 39, according to a round-robin fashion, as shown in Figure A.1.<\/p>\n

 <\/p>\n

\"\"
Figure A.1: BLE scanning\/ initiating process<\/figcaption><\/figure>\n

The advertiser periodically generates advertising events. Each advertising event consists of a sequence of advertising messages. Tad <\/sub><\/span>is the duration of time that will take for the advertiser to send an advertising message on a predefined advertising channel during each advertising event. At that time, the advertiser goes into the reception mode and listens for the duration of Tr <\/sub><\/span>on the same channel. Then, as shown in Figure A.2, the advertiser moves to the next advertising channel.<\/p>\n

 <\/p>\n

\n<\/div>\n

\"\"
Figure A.2: Advertising process<\/figcaption><\/figure>\n
\n

Two types of scanning are defined for a BLE device which are called passive scanning and active scanning. In passive scanning, a scanner receives advertisement messages, but does not send any packet to the advertiser, while in active scanning, the scanner listens to advertisement messages and after receiving an advertisement message, it sends a scan request packet to the advertiser. The scan request packet can help the scanner to learn more about the advertiser. For example, the scanner can ask about supported services by the advertiser. In response, the advertiser can send a list of its supported services.<\/p>\n

The value of Tad <\/sub><\/span>is determined by the size of an advertising message. The size of each advertising message can be as small as 80 bits or as long as 376 bits. The value of Tr<\/sub> is adjusted to the tolerable time for the advertiser to wait for the scanner\u2019s reply. The value of Ta <\/sub><\/span>represents the interval between two advertising events and consists of a fixed interval,\u00a0 Ti<\/sub><\/span>, and a variable interval which can be represented as a pseudorandom delay Trd <\/sub><\/span>. Based on BLE specifications, 20 ms \u2264 Ti<\/sub> \u2264 10.24 s<\/span>, 0 \u2264 Trd<\/sub> \u2264 10 ms<\/span>, and the value of Ti <\/sub><\/span>should be a multiple of 0.625 ms<\/span>.<\/p>\n

Since there is possibility of receiving several scan request messages <\/span>from<\/span> an advertiser by multiple scanners, <\/span>it is likely that the packets collide with each other<\/span>. If such a situation arose, each scanner should use <\/span>a <\/span>back-off strategy to minimize the possibility of collisions. <\/span><\/p>\n

After receiving an advertising message by a scanner or initiator, they can initiate a connection. Connections enable a reliable communication for data transmission. To ensure robust delivery of data, Cyclic Redundancy Checks (CRC), acknowledgements, and retransmissions of lost or corrupted data are considered in BLE connections. BLE uses Adaptive Frequency Hopping (AFH) to detect and adapt hopping sequences dynamically to the surrounding environment and provide a robust physical layer. Data encryption is also supported by connections. A connection is initialized when a scanner (central BLE) sends a Connect Request packet. When the advertiser receives a Connect Request message and accepts this request, it stops advertising and follows the parameters in the Connect Request packet to start a connection. An advertiser checks several conditions before accepting the connection request. The advertiser needs to be enabled to accept connections and should not have any whitelist or if it has one, the initiator’s address should be in the whitelist. After establishing the connection, the initiator becomes the central node and the advertiser becomes the peripheral node. The central BLE node sends a connection event message on every connection interval. And the peripheral BLE node opens the scan window on every connection interval after the first connection event. The peripheral then sends a connection event packet toward the central node which acts as an acknowledgment. This packet may contain the user data as well.<\/p>\n

The connection parameters provide information about the communication between the central and peripheral BLE node and are included in the Connect Request packet. A Connect Request packet contains several fields. The most important fields of this packet are interval, latency, and timeout. Connection Interval (CI) is the time between two BLE connection events. The peripheral BLE node specifies the minimum and maximum values of interval, but the CI value for communication is set by the central node when the BLE connection is first established. Some central BLE devices ignore the maximum and minimum values specified by the peripheral and use some default CI values instead. The duration of CI is equal to the interval times\u00a01.25 ms<\/span>. The BLE specifications state that the interval can be any value between 6 and 3200. In other words, the connection interval time can accept any value in the range of 7.5 ms <\/span>to 4000 ms<\/span>. Latency field defines the number of connection events the peripheral BLE node is allowed to skip the transmission. If the peripheral node does not have any data to send, it has the option to skip several connection events. This can provide some reduction in power consumption for the peripheral device. It should be noted that the peripheral BLE node should not stay too long in the sleep mode to lose its connection to the central BLE node. The number of consecutive connection events that the central BLE node continues its operation without receiving any data is defined as timeout.<\/p>\n<\/div>\n","protected":false},"author":197,"menu_order":1,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"back-matter-type":[],"contributor":[],"license":[],"class_list":["post-202","back-matter","type-back-matter","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter\/202","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter"}],"about":[{"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/wp\/v2\/types\/back-matter"}],"author":[{"embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/wp\/v2\/users\/197"}],"version-history":[{"count":9,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter\/202\/revisions"}],"predecessor-version":[{"id":400,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter\/202\/revisions\/400"}],"metadata":[{"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter\/202\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/wp\/v2\/media?parent=202"}],"wp:term":[{"taxonomy":"back-matter-type","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/pressbooks\/v2\/back-matter-type?post=202"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/wp\/v2\/contributor?post=202"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/pressbooks.bccampus.ca\/iotbook\/wp-json\/wp\/v2\/license?post=202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}