EddyStone基本功能涵蓋完整　Beacon應用開發一把罩

接近應用程式介面最常被用在發展與接近相關的應用，例如當使用者逛百貨公司的時候，經過不同的櫃位，就會收到對應店家傳來的優惠推播，就是一種接近應用。

不過，這個API本身是一種雲端服務，開發者可以在雲端管理大量已部署的Beacon，實現不同應用。例如基於接近應用程式介面所發展的Nearby API，可以透過訂閱(Subscribe)和推播(Publish)等API功能，讓訂閱訊息的用戶接收到臨近Beacon的推播訊息。

此外，接近應用程式介面所提供的診斷終端(Diagnostic Endpoint)功能，也可以幫助開發者管理監控各個Beacon是否運作正常。位置(Places) API則可讓使用者取得Beacon所在的經緯度以及室內樓層等資訊，作為室內定位的基礎。

實體網站顧名思義就是讓虛擬網站實體化，透過Google Beacon廣播 EddyStone-URL格式，當使用者接近Beacon時，就會收到對應的網站網址資訊。值得一提的是，其他用戶端應用程式(例如Chrome)也能利用實體網站提供的微定位資訊及應用。

例如使用者有一個可透過低功耗藍牙控制顏色的LED燈，該燈具會廣播EddyStone-URL，當使用者接近時，會打開用戶的Chrome瀏覽器，將其導入控制網頁，這網頁可透過Javascript控制手機的藍牙，進而控制這個LED燈的亮度和顏色。

這些Google Beacon的應用主要是以Google提出的開放BLE Beacon格式EddyStone為基礎。接下來將仔細介紹EddyStone格式與其設計的核心概念。

EddyStone通訊協定的封包格式，是以低功耗藍牙的廣告/廣播(Advertisement/ Broadcasting)格式為基礎所衍生出來的。

EddyStone封包與低功耗藍牙封包格式比較

關於低功耗藍牙的廣告/廣播格式，可參考藍牙標準規範中的V3-PartC-Chapter 11。

圖1是低功耗藍牙廣告/廣播封包格式示意圖，每個封包的長度固定是31個位元組(Bytes)，由多個AD Structures及Padding組成。每個AD Structure會包含1個位元組的長度(Length)資訊以及長短不等的資料(Data)，而資料又由AD Type以及AD Data所組成。

圖1 低功耗藍牙廣告/廣播封包格式

各種AD Type對應的內容可參考GAP Assigned Numbers網頁。該網頁列出各種AD Type以及AD Type的值，而此AD Type對應的AD Data則要再參考藍牙和新標準附件(Bluetooth Core Specification Supplement, CSS)這份文件。

表1是GAP Assigned Numbers網頁一部分的截圖，可以看到AD Type 0x01代表Flags，其相關定義以及對應AD Data內容則得參考CCS Part A 1.3。

表1 GAP Assigned Numers部分列表

CCS Part A 1.3的部分內容如表2。Flags代表此BLE裝置的的特性，以Bitmap方式表示，例如假設flags =0x06，那就表示它是BLE general discoverable mode，且不支援傳統的Bluetooth BR/EDR。

表2 藍牙核心標準附件第四版部分內容

對低功耗藍牙廣告/廣播封包格式有一定程度了解後，回來看EddyStone的封包格式。其封包格式是建立在Complete 16-bit UUID AD Type (0x03)以及Service Data AD Type (0x16)上面，其主要內容都是放在Service Data裡面，加入自己定義的格式。

Complete 16-bit UUID AD Type如表3所示，其AD Data為一個列表，裡面有一到多個16-bit UUID。EddyStone的Service UUID AD Data會固定為0xFEAA。

表3 Complete 16-bit UUID AD Type列表

Service Data AD Type如表4所示，可以有下表列舉的三種方式。其AD Data可以是其中一種UUID。EddyStone使用16-bit UUID，其值為0xFEAA，後面接著EddyStone自訂的資料格式。

表4 Service Data的AD Type格式

根據以上規範，一個合乎規定的EddyStone Beacon廣播封包必須如表5所示。接收端利用判斷廣播封包的EddyStone Service UUID以及其Service Data，便可以識別這是一個EddyStone Beacon的封包，並使用 EddyStone的封包格式去解析封包內容欄位。

表5 EddyStone封包格式

在進入EddyStone的資料本身之前，讀者須注意，所有EddyStone封包內的Multi-byte資料，都是以Big-Endien表示，和藍牙使用的Little-Endien不同，所以在使用的時候，要特別注意。

EddyStone-UID正面挑戰iBeacon

目前EddyStone封包分類共有三種型式，分別是UID、URL及TLM，未來可能會擴充，如表6所示。封包型式的資料會放在Service Data的第一個Byte，例如表6所表示的第11個位元組，表示之後的資料為此封包型式的資料。

表6 EddyStone封包型式

EddyStone-UID這個封包型式基本上跟iBeacon一樣，所有iBeacon可以做到的應用，EddyStone-UID都可以做到。

這個封包的功能就是廣播一個Unique ID(UID)，當應用端接收到此UID後，便可以做對應的處理，例如當使用者進入商店內，手機應用程式收到商店內Beacon廣播的UID，便將之傳送給後端做比對處理，後端再回傳此商店的折扣訊息，顯示於手機應用程式。

EddyStone-UID也可以用來實現微定位以及室內導航相關的應用。透過Beacon廣播欄位內夾帶的發射功率(TX Power)資訊，配合收訊強度指標(RSSI)和距離的理論公式，便能夠估算出接收端和Beacon的距離，加上Beacon本身的位置若是固定不變的，就有機會可以推算出使用者所在的位置，再將這個資訊導入不同的應用。

UID的封包格式如表7所示，除了第一個Byte的UID封包類型外，其他的內容分別是傳輸功率資訊、名稱空間ID(Namespace ID, NID)、副本ID(Instance ID, BID)、以及兩個保留給未來應用的欄位(RFU)。

表7 EddyStone-UID封包格式

第二個位元組包含的是用來做距離估算的傳輸功率資訊，其數值是距離此Beacon 0公尺時可接收到的訊號功率，單位是dBm，值的範圍是-100∼20。每個Beacon的功率強度可能不同，需要做精確的量測後填入，而量測方式通常的做法是將距離此Beacon 1公尺遠時所量到的訊號強度加上41dBm。

第三到第十二個位元組是NID，長度為10個位元組，可以自訂。NID加上BID就能構成UID。NID機制可以加快篩選出特定Beacon的速度，例如先篩選出NID屬於自己的Beacon後，再去看BID。

值得注意的是，NID雖然可以任意自訂，但為了避免跟別人選到一樣的NID，影響Beacon服務，官方官方建議兩種選擇NID的方式，分別是完整網域名稱(Fully Qualified Domain Name, FQDN)經過SHA-1 Hash演算後，結果取10個位元組；或是產生一個Version 4 UUID並去掉第五到第十個位元組後，就可以得到長度為10個位元組的NID。

BID的長度是6個位元組，可用來識別在同一個NID下的Beacon。其數值可以用任何方式來編號，例如流水號、亂數等，只要方便應用端使用就可以，但同一個NID下面的Beacon要具備不同的BID。

EddyStone-URL：提供URL位址虛實整合應用開發利器

EddyStone-URL的前身為 UriBeacon，算是其進階版本。這個封包格式主要功能就是廣播一個網址，當用戶端收到此廣播的時候，便可以解析此網址，然後決定是否打開這個網址。換言之，EddyStone-URL可以說是個接入點(Entry Point)。藉由此入口打開網站，就可以開始進行相關的互動或應用了。

廣播網址會遇到一個問題，就是一個網址放進低功耗藍牙廣播封包的話，很容易就會超過限制的31個位元組，因此 EddyStone-URL這個網址廣播格式還導入了一個編碼URL的方式，讓大部分URL都有機會可以塞進廣播封包內，接下來的內容會針對此編碼方式做一個介紹。 EddyStone-URL 封包格式如表8所示，除了第一個位元組為EddyStone-URL封包型式外，其他內容分別是傳輸功率、網址前綴(Prefix)、URL字串。

表8 EddyStone-URL的封包結構

傳輸功率與EddyStone-UID的欄位相同，不再贅述。網址前綴是第二個位元組，目前其數值有四種選擇，如表9所示。URL字串則是接在前綴後的URL字串，最長可以寫到17個位元組，因為表頭(Header)已經使用了14個位元組，而EddyStone封包的長度固定為31個位元組。值得注意的是，URL字串一樣可以用編碼的方式來縮減長度。表9整理了特定編碼所代表的字串值，其餘不在表上的，就代表此位元值對應的ASCII字符。

表9 EddyStone-URL的網址前綴編碼

表10 縮減URL字串長度的特殊編碼對照表

了解以上的URL編碼方式後，表11是將https://www.test.com/b.htm這個URL按照EddyStone-URL規則轉換後，利用Beacon廣播出來的數值，供讀者參考。

表11 按照EddyStone-URL規則轉換後的URL編碼範例

EddyStone-URL還可以有一個選擇性的藍牙通用屬性設定檔組態服務(GATT Configuration Service)，這個服務讓管理者可以直接透過低功耗藍牙設定EddyStone-URL相關的參數，例如廣播的頻率、使用的傳輸功率，甚至設定廣播的URL內容等，詳情可參考官方網站的介紹。

遠端掌握Beacon設備狀態 EddyStone-TLM派上用場

最後要提的封包型式是EddyStone-TLM。TLM為Telemetry的縮寫，也就是遙測資訊。其主要用途是廣播Beacon設備本身的狀態資訊，例如電量、是否正常運作以及量測和統計資訊。

因為TLM本身沒有ID資訊，所以TLM可以跟著UID或是URL等封包型式一起使用。例如有一組UID Beacon正在線上提供應用服務，管理者想遠端監控這組 Beacon的狀態，確認是否需要更換電池，就可以使用EddyStone通訊協定搭配 UID格式，然後偶爾傳一下TLM格式，來達到此效果。

上面提到的方式稱為間歇性遙測(Interleaving Telemetry)，也就是UID或URL封包和TLM封包按照一定比例交叉廣播，例如1:1或是固定每個小時只廣播一次TLM，端看應用針對TLM需求的頻繁程度，例如只用TLM來偵測電池電量的應用，每小時或更久廣播一次TLM，就已經足夠了。

要注意的是，既然UID或URL跟TLM不是存在於同一個封包，而是交叉傳送，接收端必須透過低功耗藍牙的媒體存取控制位址(MAC Address)來識別此UID 或URL和TLM是否是同一台Beacon設備發出的。若Beacon要使用動態的MAC Address，必須特別注意這點。

EddyStone-TLM封包格式如表12所示，除了第一個位元組用來表示EddyStone-TLM的封包型式外，其他內容分別是TLM版本(TLM Version)、電池的電壓(VBATT)、設備溫度(TEMP)、開機後共送出多少個廣播(ADV_CNT)、開機後至今的時間有幾秒(SEC_CNT)。

表12 EddyStone-TLM封包內容格式表

TLM版本的長度為一個位元組，目前只有0x00可以被接受，但未來可能會有新的版本，後面的欄位數值應該會有不同。

電池電壓(VBATT)的長度為兩個位元組，數值的單位是毫伏特(mV)，最高可表示到65,536mV。但也可以轉換成電池剩餘電量的表示方式，計算方式是目前電池電壓/充飽電時電池電壓。如果該Beacon設備透過USB供電或不具備電池，可以填0。

設備溫度(TEMP)表示設備偵測到的溫度資訊，單位是攝氏度(C)，假如設備不支援這個功能，則填入0x8000表示-128度。

EddyStone標準相對完善　應用開發效率高

相較於目前市面上各種Beacon的格式，Google EddyStone應該算是最完整完善的一個標準，且結合其他Google API後，更可以更快速完成Google Beacon相關的應用。筆者非常推薦想開發Beacon服務的企業可考慮使用EddyStone，或者在充分理解EddyStone設計的精髓後，自行修改出自己專屬的Beacon封包格式，以避免被其他第三方應用程式蒐集到廣播中的相關資訊。