Note: NB-IoT and CAT-M1

NB-IoT 又稱 LTE CAT-NB1, 是一個由3GPP 組織定義非即時的用於物聯網的傳輸規格, 規格設計很巧妙地使用LTE 的GuardBand 的頻帶, 不過也保留使用GSM時代的200KHz頻帶, 當然要用Inband 的話也是可以, 下面是3GPP目前的一些使用頻帶現狀

3GPP has defined a set of frequency bands for which NB-IoT can be used. 3GPP TS 36.101 [9]from Release 13 provides the list of the supported bands: 1, 2, 3, 5, 8, 12, 13, 17, 18, 19, 20, 26, 28, 66 and Release 14 added the bands: 11, 25, 31 and 70. Release 15 added further bands: 4, 14 and 71.The input received by the NB-IoT Forum members, so far, indicates a variety of bands have been used. Below is an overview of the frequency bands supported in the different regions:

  • Europe: B3 (1800), B8 (900) and B20 (800);
  • Commonwealth of Independent States: B3 (1800), B8 (900) and B20 (800);
  • North America: B4 (1700), B12 (700), B66 (1700), B71 (600), B26 (850)
  • Asia Pacific: B1(2100), B3(1800), B5(850), B8(900), B18(850), B20(800), B26(850) and B28(700);
  • Sub-Saharan Africa: B3(1800) and B8(900);
  • Middle East and North Africa: B8(900) and B20(800);
  • Latin America: B2(1900), B3(1800), B5(850) and B28(700)

而台灣目前使用的應該是 B3/B8/B28 為電信三雄,
中華電信主要為 B3/B8
而遠傳與台灣大哥大主要為B28
NB-IoT的主要應用場景有其侷限性, 他的設計是非即時性與小量資料, 並可以盡量的省電, 省電就是系統需要保持在 in-active的情況下才能達成, 並且因此失去移動跨越基站的可能性, 只能在固定場域使用(update: R14 增加了低速移動的可能, 可以讓傳遞相關訊息接換到新的基站)
基本的特性如下
Latency Time: 1.6 ~ 10 Seconds
Data rate:
Up-link, 250Kbps for Multi-tone, 20Kbps for Single-tone
Downlink, 250Kbps
Half-duplex
Link-budget:164dBm
而實際經過eDRX & PSM 等網路設定, 往往會再增加其Latency

而LTE CAT-M1, 的M是Machine to Machine 的意思, 他設計基於 LTE inband設計, 利用既有LTE 的設計規範可以相容2~4G的系統, 但需要升級網路的軟韌體組態, 他相較於NB-IoT 有下列的不同
較低的Latency time, (10 ~ 15 miliiseconds)
較高的資料傳輸率, (1Mbps, Full/Half-duplex)
較小的覆蓋率(Link-budget: 155.7dBm)
較高的功耗, 但也因此具有Handover 的特性, 可以如一般傳統應用一樣具有移動性, 與支持語音通話的可能

因為特性的不同, 沒有一種可能簡單的適應各種不同的應用場域 ,因此在發展IoT的系統架構時, 需要先依據所需的應用場景特性去選擇合適的聯網技術或是混和各種不同的LPWAN使用才能有較佳的系統表現

廣告

Note: MQTT-SN and CoAP

MQTT-SN(Sensor Network), 透過預先註冊Topic 將Topic string 轉成Token/Id 減少每次傳遞訊息的需要重複的topic string, 並透過UDP
 
CoAP 是Sensor 端是CoAP server 可以被Discovery resource/operation 設計, 然後透過push message 來傳達狀態更新給CoAP client

Note: OPC UA for IIoT

OPC UA 一個被許多大廠支援的標準, 標準文件為 IEC 62541 從官網上看來目前主要的開發環境還是圍繞Windows 發展, 不過OPC UA的目標就是為了廣泛適應不同平台開發才誕生, 而早期相依Windows 的OPC DCOM 目前被稱為 OPC Classic

目前可以看到許多大廠已經是該組織主要成員, 在SCADA/ERP系統橋接與資料收集上, 必定成為主流, 因此也被稱為IIoT(Industry IoT)/Industry 4.0 的基礎協議, 用來做M2M的訊息交換與控制用的

從官方的Github 來看目前會走向, 透過Meta/Schema 文件(.xml) 產生相對應的 C#/C++ code 讓M2M實現得更容易一些

Note: Protobuf with MQTT

這幾天在寫實際的Protobuf + MQTT 的程式, 今天重新編了,  Paho C/C++ library 後, 在Windows上終於連到 broker.hivemq.com 這個公開用來測試用的Server, 目前看起來工作正常, 但是這讓我開始有一個疑慮, 如果用Protobuf這種序列化/反序列化的程式庫, 那是否會有那種隱含的安全問題?  應該只能用安全連線的通訊環境下吧? 不然光是處理檢查進來的Stream是否合法安全就搞不完了.

做Demo 還是可以用這種公開的Broker server, 實際商品化就必須採用login/password, 跟SSL的Server, 這樣的話MQTT本身的payload加不加密也就不重要了, 或是將message本身加密, 能正常解出的也代表是 Trusted ? 也應該是一種方式。

另外 hivemq 的Websocket for Browser 當message payload 不是用json/text格式的話,  應該是收不到訊息的, 不知道是底層就收不到還是上層 因為解不出 Text就是不會有反應, 所以早期開發如果要方便除錯採取json 還是一個比較快的方式

 

Note: About MQTT

本來上週末在看gRPC 想說先做單對單的設計展示之後上雲的可能性, 但是計畫趕不上變化, 老闆找了大老闆展示部門之前做的東西跟未來要做的東西後, 大老闆明顯想要的是直接上雲可以一步到位展示給終端客戶推廣的東西, 因此需要重新構思設計方向, 做了一下技術選擇, 應該還是MQTT比較合適, 而且目前有明確需要上雲的東西

目前看了一下主要就是Device 需要設計 publishes 的Topic 跟Payload, 還可以設計 subscribe topic, 讓遠端傳遞控制命令

找到一篇算是很不錯的基本文介紹 MQTT Topic and Payload Design Notes  還加上他有一篇 payload 加密文 How to Encrypt MQTT Payloads with Python – Example Code 剛好都是我能做的, 剩下就是構思實際使用的Topic結構設計 說是Topic 實際上這也是一種Service API設計

另外 HiveMQ 除了提供企業級的MQTT的各種服務外也為了推廣業務寫了一堆基礎介紹好文

MQTT Essentials

可能是我資質不夠吧 XD本來看了幾篇中文介紹跟範例都抓不到實際使用的好方法, 反覆看了幾篇實際案例後 才腦洞大開知道怎樣用才對, 下週如果沒有其他外務打擾應該可以先做一個demo 給老闆看, 然後再繼續做UI 跟著做Web Service

不過個人覺的MQTT這種用法還是有點浪費頻寬, 雖然對開發過程友善,  但是每次要把已經知道的結構都傳一次, 不能設計一種先傳 meta structure,  然後後面直接用reference 的設計嗎? 不過好像最近有MQTT 5.0 的protocol release 不知道會不會有, 不過meta struceture 設計變成後面加入的訂閱者會收不到,  但是如果加入類似Service Discovery 去跟Broker 查詢應該就可以克服, 不過這樣Broker 負擔會變重就是了

Note: Windows 10 IoT core

這個目前還是有一些工控領域有對應市場, 然後很多應用不用royalty fee 所以會有經濟誘因,

不過對於技術人員來看, 做這個image 開發有點介於以前的Windows Compact Embedded 但是大部分接近於原生Windows Embedded 的image build 工作, 簡單講就是客製化的彈性相對少很多, 會極度趨近原生Windows

需要 ADK/WDK 要一致的版本編號 確保OS API/DDI的變化, 這樣變成如果商用有不同版本需要維護會需要切換安裝版本, 應該可以透過環境變數控制, 這需要測試一下

然後 Image 這時簡單分為開發與測試用的Test, 跟實際出貨的Retail

buildimage ProductA Retail/Test

Image 的產生流程可以參考IoT Core manufacturing guide

ref.

Note: golang with docker

Docker 這幾年對於各種運維很流行,實際上在開發各種嵌入式裝置與Android BSP維護上也會遇到很多相依性問題,這一兩年也看到越來越多公司開始採用 Docker 去維護開發環境了,尤其當你需要多地協同開發時,與第三方客戶或是夥伴開發更是如此,可以透過設定好的Dockerfile 去做開發環境的維護,降低各種溝通與反覆試誤的成本。

這裡舉一個 台灣工控一哥的例子 可以看到連結內有許多不同OS版本對應的不同開發環境,這樣你開發的環境不用去管理各種不同版本的套件相依性問題,對客戶跟第三方合作廠商都可以快速的發布,對於有多樣客戶是一個相對省力的支援方式

因為IoT Era 的到來,今天測試一下Docker 做Golang 開發

底下是一個 golang with git, gcc and make 的Dockerfile,用的是Alpine distribution, 要改成其他Distribution 也可以, 官方有Debian可選 , 可以直接用Docker pull golang:$tagname 之類的方式去拉下image
下面是我新增git & make & gcc 的開發用Dockerfile

FROM golang:1.10.1-alpine

RUN apk add --no-cache git make gcc

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH

然後可以參考官方文件的Docker-compose 去結合其他service 像是資料庫PostgreSQL
這樣可以開發一些Microservice 來做一些應用,需要水平擴展時可以加上反向代理等等,做現在所謂雲端的開發

如果想放像DockerHub 讓大家都可以使用你的Dockerfile 也可以參考工控一哥的這篇

透過上面的Dockerfile 可以用docker build 變成image 我這裡用 docker tag 改成 mygolang
透過docker image ls 可以看到下面狀況

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
mygolang            latest              2da237294097        2 hours ago         475MB
golang              1.10.1-alpine       52d894fca6d4        5 days ago          376MB
postgres            9.6.8-alpine        b27674feae2a        6 weeks ago         38MB

然後建一個 docker-compose.yml 如下, golang 那區塊應該有點問題還需要更正

# Use postgres with golang
version: '3'

services:
    db:
        image: postgres:9.6.8-alpine
        restart: always
        ports:
            - "5432:5432"
        environment:
            POSTGRES_DB: dev
            POSTGRES_PASSWORD: IdQuivgebobr9Dra
            POSTGRES_USER: postgres
    go:
        image: mygolang:latest
        ports:
            - "8080:8080"
        working_dir: /go
        depends_on:
            - db
        links:
            - db

然後下 docker-compose up -d 這樣會出現

Starting mydocker_db_1 ... done
Creating mydocker_go_1 ... done

在接著用 docker-compose run go 重跑一次mygolang 這樣就可以開始開發相關service
透過 docker-compose ps 可以觀察到下面 container status

      Name                     Command              State            Ports         
-----------------------------------------------------------------------------------
mydocker_db_1       docker-entrypoint.sh postgres   Up       0.0.0.0:5432->5432/tcp
mydocker_go_1       /bin/sh                         Exit 0                         
mydocker_go_run_1   /bin/sh                         Up

Update: 這篇還沒整理完,參考 Where and how to persist application data 可以知道應該透過Volume/Bind 跟Host的目錄連結,這樣才能持續開發並且不增加container 需要在花一些時間整理
至於一些使用Docker 快速提示可以參考這個 docker cheatsheet