Castle on a Cloud

在 上一篇文章 中, 我們介紹了 LTE 網路的下行方法, 接下來, 我們會從 OFDMA 出發, 介紹上行的 SC-FDMA, SC-FDMA 全名為: Single-carrier FDMA, 其特色就在於只有一個載波頻率, 這樣的特色, 似乎和原有的 FD (Frequency Division) 相悖離, 因此, SC-FDMA 不像 OFDMA 一樣直觀, 我們先從 OFDMA 和 SC-FDMA 的多工比較出發, 如下圖所示: 來自:  http://www.rfwireless-world.com/Articles/difference-between-SC-FDMA-and-OFDMA.html 在左圖即是原本的 OFDMA 的調變多工, 每一個 symbol, 被放在一個 15 kHz 的 RE 中, 而又圖則是 SC-OFDMA 的調變多工方式, 我們可以看到原本在頻率軸上的多工 (不同顏色, 不同 RE), 轉移到時間軸上, 因此, 此電波信號是在時間上多工.

在 LTE 系統中, 上行 (uplink) 和下行 (downlink) 使用不同的調變技術, 對於下行而言, 使用 OFDMA 的調變技術, 而對於上行而言, 則使用 SC-FDMA 的技術, 在一般的介紹文件中, 都會說到兩者的差別在於: PAPR 也就是傳送訊號的峰值/平均功率比 (peak-to-average power ratio), 由於此數值較低, 可以提升使用者端的發送效率, 例如: https://zh.wikipedia.org/wiki/SC-FDMA 但是, 這兩種調變技術的真實差別, 在中文網站中, 卻少有系統的整理, 因此, 這一系列文章, 就整理一下對於此兩種調變技術的了解, 作為 SC-FDMA 和 OFDMA 的介紹. 首先, 我們從 OFDMA 開始, OFDMA 全名為: Orthogonal Frequency Division Multiple Access, 簡單來說, OFDMA 將通道資源以頻率和時間切成許多許多小方塊 (resource element, RE), 不論 LTE 使用多寬的頻寬作為傳輸, 每一個小方塊在頻率上都是 15 kHz 的寬度, 在時間上, 則回隨著 CP 的不同, 而有不同設定, 可以參考下表: 來自於:  https://goo.gl/tUedLM

對於 LTE 基地台內的時間同步, 主要是依賴 eNB 發出的兩種訊號: PSS, SSS, PSS 全名為 Primary Synchronization Sequence, SSS 全名為 Secondary Synchronization Sequence, 這兩個訊號除了進行同步之外, 也幫助 UE 搜索並辨識基地台, 來自: http://www.telecomsource.net/showthread.php?3122-What-is-significance-of-Synchronization-signals-in-LTE PSS 有 3 種固定的格式 (Zadoff-Chu 序列), 藉由 match filter 的方式來搜尋, UE 會先對齊中心頻率, 接著在找到正確的 frame time 完成同步, 藉由 PSS, UE 可以找到正確的頻率和時間, 以確保其傳送的資料不會對其他 UE 所使用的 RB (resource block) 產生干擾, 因此, 辨別 PSS 訊號同時也是 UE 進入 LTE 網路的第一步, PSS 訊號每 5 ms 會重複出現一次, SSS 訊號緊跟在其後, SSS 訊號一共有 168 種可能性 (M序列), 因此, PSS 和 SSS 加起來一共 504 (3*168) 種可能就用以辨別不同基地台, 此辨別資訊稱為 PCI (Physical Cell Identity), 對於同步問題而言, SSS 有兩種不同的組合交替出現, 因此, 可以用來分辨前面的 PSS 是在 1 ms 還是 6 ms 的時間, SSS 除了用以輔助 PSS 來進行定外之外, SSS 還提供了額外兩個資訊: TDD 或是 FDD 系統, CP (Cyclic Prefix) 的長度, CP 是用來設計對抗 multipathing 的效應, 對應於不同的通道環境, LTE 提供兩種不同的 CP 長度設計, 我們可以藉由量測 PSS 和 SSS 之間的間隔時間, 來得知 CP 的長度, 來自: http://blog.sina.com.cn/s/blog_927cff0101019un0.html 另一方面, 對於 FDD 和 TDD 的系統而

對於一個通訊系統來說, 同步是一個重要, 但是常常被忽略的問題, 大致上的原因就是因為同步的研究已經發展久遠, 相關的技術也都成熟, 然而, 考慮到一個以排程為基礎的通訊系統, 使用者裝置 (UE) 和基地台 (eNB) 之間必須要能夠同步, 才可以透過排程機制, 避開使用者在同一個時間內的干擾, 若是沒有同步機制, 換句話說, 排程機制也將失效, 在LTE系統中, eNB之間的同步可以分成三種不同的分類: Frequency synchronization (頻率同步) Phase synchronization (相位同步) Time synchronization (時間同步) 其中的差異可以表示如下圖: Bladsjö, David, Marie Hogan, and Stefano Ruffini. "Synchronization aspects in LTE small cells." 頻率同步只同步每一個frame的間隔, 換句話說, 每一個eNB都使用相同的reference signal作為時間參考, 然而, 考慮到不同的eNB延遲, 每個eNB可能會差距一些時間, 這個是LTE網路在FDD架構下的的最低同步要求, 相位同步則要求每個eNB都必須要能夠在同一時間傳輸封包, 每個eNB的時間軸必須對齊, 不能有任何差異, 這樣的要求, 是對於TDD框架下的LTE系統, 為了避免不同基地台在時間上的干擾, 每一個eNB都需要相位同步, 最後的時間同步則是指, 所有eNB都擁有相同的global time, 此時, 不只傳送的frame可以對在一起, 連時分秒也都是一致, 對於三種不同的同步要求, 達成的方法也不一樣, 對於頻率同步, 只需要每一個eNB參考同樣一個時脈訊號源, 對於第二種和第三種同步要求, 我們可以利用網路同步 (NTP) 的方法, 利用有線的訊號交換, 來對齊eNB的時間, 在此方法中, 我們需要在核心網路中架設相當於NTP伺服器的PTP伺服器, 假設在多重核心網路的架構下, 所有eNB都必須參考到相同的時間來源, 或者, 我們也可以利用GPS訊號進行同步, GPS訊號為來自於不同衛星的一組時

一般來說, 我們會從兩個角度描述一個通訊網路的關係, 首先, 我們會有一張系統架構圖, 用來描述各裝置的位置, 以及相互之間的關係, 如果更詳細一點, 應該要畫出裝置中各元件在SPEC中的定位, 以及裝置間個連線, 在SPEC中所使用的接口, 接下來, 我們需要有另一張資料流程圖 (data flow), 來表示控制訊息和資料訊息在裝置間(或是元件間)的時間關係. 然而, 不幸的是, oneM2M的TR0001雖然提供了大量的使用案例, 但是每一個案例的細節卻參差不一, 若以較為嚴格的標準來看, oneM2M提供的案例, 都無法直接的套入框架, 不過, 我們仍找一個較為完整的案例作為範例, 說明如何了解oneM2M的資料流程, 我們以9.1的Home Energy Management為例(pp. 73, TR0001 V2.4.1), 一開始, 違建會先用文字介紹環境以及目標 (9.1.1 Description), 接下來, 介紹會出現的裝置和標準 (9.1.3 Actors), 這一部分可以看做系統架構圖的文字版, 幸運的是, 該使用案例有畫出系統架構圖 (figure 9.2), 來自:  http://www.onem2m.org/images/files/deliverables/Release2/TR-0001-Use_Cases_Collection-V2.4.1.pdf

通常, 我們寫通訊架構的文章資料來源有二: 上網搜尋閱讀別人摘要, 或是閱讀SPEC, 閱讀別人的資訊再整理, 的確能夠快速地了解架構, 然而, 畢竟是二手資訊, 如果仍有疑問, 還是要回到官方的文件, 也就是SPEC上 OneM2M的SPEC和3GPP的形式一致, 分成TS (Technical Specification) 和TR (Technical Report), 網址如下: http://www.onem2m.org/technical/published-documents TS是正式的SPEC, 會規範通訊中的細節, 以TS 0001為例, 標題為: Functional Architecture, 裡面就涵蓋了之前文章的多數內容, 比如說, 在第6章, "oneM2M Architecture Aspects", 就介紹了四種節點 (Node) 的定義與相互的角色, 包括: Application Service Node, Application Dedicated Node, Middle Node, Infrastructure Node, 然而, 由於這是SPEC文件, 所以不會有詳細的說明和舉例, 通常只有一到兩句的定義 TR則是在定義SPEC之前討論所產生的技術文件, 以TR 0001為例, 標題為: Use Cases Collection, 就集結了各家提出來OneM2M的使用環境設定, 通常, 我們會從這份文件讀起, 嘗試了解SPEC定義者心目中應用架構, 再一步步推廣到其他細節. 不過, OneM2M和3GPP的SPEC仍有很大的差距, 根據我之前讀TR的經驗, 3GPP文件不論是圖, 表, 文字, 內容, 都十分一致, 但在OneM2M的文件中, 卻有一種像是剪貼簿的感覺, 只是把各家報告複製貼上, 而缺乏整合...

讓我們在這裡總結一下前幾篇文章對oneM2M的介紹, 並嘗試系統化oneM2M的架構. 在oneM2M的架構中, 分成3種基本單元: AE: Application Entity CSE: Common Service Entity NSE: Network Service Entity 以上3個單元, 分別對應於Application Layer, Service Layer和Network Layer, 其中, 在之前文章中, NSE沒有詳細的介紹, 根據定義, NSE provides connectivity services to the CSEs besides the pure data transport. 換句話說, NSE提供CSE基本的資料傳輸功能, 用以建立網路, 若以在網路中的角色來分配, oneM2M有4種不同的節點: Application Dedicated Node Application Service Node  Middle Node  Infrastructure Node. 這四個節點以Middle Node為界, 分屬於兩個網路: M2M網路, 網際網路, 或是以oneM2M的術語來說, 就是field domain 和 infrastructure domain, Middle Node像是gateway一樣, 扮演兩個網路之間資料轉傳的角色, Application Dedicated Node和Application Service Node的差別在於CSE的有無, 換句話說, 若是傳統無oneM2M的裝置, 即是Application Dedicated Node, 若有CSE層, 則是Application Service Node, Application Dedicated Node和Application Service Node同屬於M2M網路中的節點, 關係如下圖: 來自:  https://www.slideshare.net/Hamdamboy/one-m2m-66797390

交大資工林甫俊老師有一篇文章介紹OneM2M, 很值得一看: http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 在該篇文章中, 借用了我們較為熟悉的網路流程, 也就是: 感測器->資料庫->應用, 的架構, 並定義了兩種網路: M2M設備網路, 以及M2M核心網路, 其中介於兩種網路之間, 就是閘道 (gateway), 因此, 架構圖就會表示如下圖: 來自於:  http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 對照 上一篇文章 中的圖示, 我們可以找到其對應關係: Application Service Node (應用服務Node): M2M設備區 Middle Node (中間Node): M2M閘道 Infrastructure Node (基礎設施Node): M2M網路區

在 上一篇文章 中, 介紹了OneM2M的目標以及所處位置, 在這一篇文章中, 將繼續介紹在OneM2M中, 裝置所虛擬化的基本單元. 不同於一般行動網路的通訊協定, 定義了核心網路以及接取網路的架構, OneM2M不提供網路服務, 所以沒有核心網路的設計, 而把自己視為一個轉介層, IoT終端透過此轉介層, 回傳所收集的資料, IoT的應用服務, 也透過此轉介層, 訂閱所需要的資料, 因此, 在OneM2M的架構下, 可以區分出兩個主要的基礎單元: AE (Application Entity): 可以是裝置, 也可以是應用服務 CSE (Common Services Entity): 提供OneM2M溝通介面的裝置 其中關係如下圖所示: 來自:  https://www.slideshare.net/onem2m/onem2m-release-1-primer/54

OneM2M:  http://www.onem2m.org/ 在之前的一系列文章中, 介紹了許多IoT的協定, 其中, 考慮到IoT裝置的省電需求與運算能力限制, 通常不會賦予完整的應用, 而是以資料蒐集, 處理, 以及傳輸為主, 對於IoT應用的架構者而言, 通常是藉由資料庫的查詢, 取得收集的資料, 並透過控制指令, 間接的操作IoT終端裝置, 對於像是SigFox這種封閉式平台當然沒問題, 只要設定好回傳的資料, 週期, 等參數設定, 就能夠自動地把資料回傳到SigFox的資料庫, 而使用者可以直接對資料庫進行操作, 抓取資料做進一步分析. 然而, 對於Bluetooth, Zigbee之類的通訊協定要怎麼處理呢? 這些通訊協定, 通常只定義了MAC和PHY的通訊協定, 而不包含TCP/IP層的協定, 無法提供後端聯網功能, 因此, 在過去, 都是由開發者自行處理資料的轉傳, 儲存與處理, 好處是開發者可以掌控所有細節, 但也堆高了開發成本, 無法像SigFox一樣包裝成應用服務使開發者容易上手.

對於通訊應用來說, 我們通常可以從兩個角度來看: 也就是行動網路 (mobile comm.) 和無線區域網路 (wireless area network), 或者, 更久遠一點的: 電話網路 (telecom) 和資料網路 (datacom). 雖然最近幾年, 兩者的差距越來越小, 但是, 畢竟來自於不同的出發點, 對於系統架構也有不同想法, 來自:  https://www.leverege.com/blogpost/lpwan-benefits-vs-iot-connectivity-options 在這張圖中, 我們通常把左方 (802.11系列) 和下方 (802.15, Bluetooth) 歸類於WAN, 2G, 3G, 4G, 5G 則是行動網路, 我們可以看到, LPWAN正好鄰近於802.15和2G, 也因此, NB-IoT的通訊方式, 更近於2G (Sigfox, LoRa, 更經典的是EC-GSM-IoT), 對於Bluetooth, WiFi而言, 發展IoT網路的阻礙反而來自覆蓋範圍.

在之前的文章中, 我們介紹了兩個陣營的IoT通訊方式, 對於比較不同的通訊協定, 或是通訊系統而言, 事實上, 調變方式, 功率, 等底層通訊框架反而不是最重要的, 畢竟, 通訊技術的決定, 一向是投票決定的結果, 不同的通訊技術, 常常可以到達相同的成效, 然而, 比較上述幾個cellur-based IoT通訊協定, 包括: LTE-M, NB-IoT, Sigfox, LoRa這四種通訊協定. 在商業應用的選擇上, 仍然有幾個需要注意的地方, 來自:  http://3smarket-info.blogspot.tw/2016/06/lora-nb-iot.html 首先, 我們先說他們的共同特色: 低功率, 便宜的晶片, 少量的資料傳輸 盡量適用低頻的通道, 窄頻譜 (LTE-M除外) 大基地台, 廣大的覆蓋範圍 這些共同的特色也造成了cellur-based物聯網適用的應用例, 也就是在大範圍為的地區, 進行資料的收集, 用以對抗有線網路和電源缺少的使用情境.

在 上一篇文章 中, 我們雖然介紹了NB-IoT為蜂巢網路下的IoT架構, 但是, 事實上, 蜂巢網路架構下的IoT仍有其它的競爭者, 包括LoRa, 以及Sigfox. 包括LoRa和Sigfox的共通特性就是兩者都使用1GHz以下的頻帶, 在通訊領域中, 越低的頻譜, 其指向性差, 可傳輸性遠, 可以用較低的功率覆蓋極大的範圍, 但是, 其能夠傳送的傳送速率較低, 因此, 適合用作IoT的應用, 以調變技術而言, LoRaWAN使用chirp spread spectrum, 為一種展頻通訊的方法, 而Sigfox則使用窄頻BPSK的方式調變, 相較LTE-based以OFDMA作為調變的方法, 可以省下運算所需要的功率, 但也更難和手機裝置整合, 傳輸的速率也因此受到限制, 我們先看一張比較圖, 比較LoRa, Sigfox和LTE-based的IoT差異 雖然原文中未寫明, 但是Narrow-Band應該就是 Sigfox 來自:  http://thinkingiot.blogspot.tw/2016/08/iot-lora-lpwan-1-lora-lorawan.html 這張表, 很明顯應該是LoRa方製作的, 因此, LoRa在除了傳送率之外的所有項目都勝出, 但是, 以一個非同步的通訊標準 (LoRa和Sigfox都是) 而言, 沒有限制的上傳的限制, 意味著, 封包無限制的碰撞, 可以想像在室內有10個WiFi AP時, 並不會有10倍的傳輸量, 反而導致所有AP都因為封包碰撞, 而無法正確送達, Sigfox把上傳限制設為一日140個訊息, 一個訊息12 bits似乎是較合理的作法, 另一方面, Coexistance, 也就是和其他基地台, 或是通訊系統的共存, LoRa因為有random backoff和展頻的機制, 因此可以做到較好的共存, 但是, Sigfox部分, 我並沒有看到如random backoff的機制, 可能會被其他基地台甚至是LoRa的用戶干擾. 最後, 雖然上表並未提及, 但是Sigfox目前並沒有提供下行的資料傳輸, 而LoRa則把裝置分成三個等級, 分別設計其下行傳輸方式, 沒有下行, 對於通訊系統而言, 是一件好玩的事情, 一方面, 這樣設計

就和所有的科技進展一樣, 首先, 有一個漂亮的標題或是願景, 像是: 萬物聯網, 然後, 是各式各樣的通訊技術的競爭與合作, 直到最後, 我們才找到一組可行的通訊協定, 推廣, 普及, 從發想到實踐, 大概是10年, IoT不是新概念, 從電腦開始, 到智慧家電, 以及最後的萬物聯網, 都是IoT的應用 http://monipag.com/antoine-michel/iot-conclusion/ 物聯網 (Internet-of-Things, IoT) 也是相同的概念, 事實上, 此概念並不新, 在WiFi網路中, ad-hoc網路就曾經是熱門話題, 低功率應用, 從當年Zigbee, Bluetooth兩家爭搶, 到現在LoRa (Long Range), Bluetooth, WiFi互相爭奪市場與應用, 但是, 市場依然沒有像當年預想的普及, 實際的應用範例反而偏向工業上的物流管理等專業的場域, 而現在3gpp加入戰場, 讓IoT的議題更受矚目, 也希望憑著3gpp聯盟廠商間更緊密的關係, 能夠藉由一致的標準, 快速提供低價且普及的IoT接取, 然而, 問題在於: 行動網路 (cellular network) 的架構並不適合物聯網 (IoT).

在上一篇文章中, 介紹了 iBeacon 的定位技術, 但是, 對於行動通訊商而言, 另一個更為可行的定位方案是Terrestrial Beacon System (TBS), TBS是一種模仿GPS的定位技術, 在R13的架構下, LTE正式宣布了對此技術的支持, http://www.nextnav.com/news/3gpp-release-13-specification-adds-support-metropolitan-beacon-system-mobile-systems 在介紹TBS之前, 我們先概述一下GPS的技術, GPS是一種基於接收時間的定位技術, 首先, 我們假設天空中有4個同步的GPS衛星, 不斷放出帶時間標記的訊號, 且我們根據星圖知道這4顆衛星的位置, 接收裝置就能夠簡單的根據接收到訊號的時間, 推斷距離這4個衛星的距離, 進而算出: 經度, 緯度, 高度, 時間, 這四個訊息, 完成定位結果的運算. 來自:  http://gpsworld.com/indoor-location-breaking-through/ 而TBS就可以視為一組在地面上的GPS衛星, 一樣發送帶有同步的時間訊號, 在空曠空間中, 可以增加GPS定位中的參考座標, 減少運算所需的能力, 降低接收訊號的雜訊, 進而提供更為準確的定位結果.

在幾年前, iBeacon大概是最流行的定位技術, 這個由Apple所提出的定位規範, 結合了低功率藍牙 (Bluetooth Low Energy, BLE) 作為定位參考點, 以廣播的方式, 讓相同有藍牙接收器的裝置 (如: 手機), 能夠得知自己的地理位置. iBeacon的節點提供不同的功率設置, 以及廣播週期設計, 前者是用以調整iBeacon的訊號接收範圍, 大致分成三個等級: 10公尺, 數公尺, 數公分, 當使用者裝置接收到iBeacon節點的訊號時, 利用藍牙通訊中的識別碼 (UUID) 來分辨接收的iBeacon節點, 至於廣播周期則是用以決定多久發送一次iBeacon的廣播, 此週期可以調整從100ms (0.1秒) 到數秒, 按照不同的設定, 一顆水銀電池最多可以提供1~3個月的使用時間, iBeacon情境圖, 來自:  http://www.digitalavmagazine.com/en/2015/01/15/ibeacon-tendencia-innovadora-en-la-organizacion-de-eventos-para-interactuar-con-el-usuario/

雖然NR的架構尚未決定, 但是對於定位的規範已經開始討論, 在3gpp文件 RP-161576 中, Intel負責整理了NR對定位的需求, 我們列點如下, 並取重要的內容說明: The NR should enable, and improve if suitable, state-of-art positioning techniques, such as RAN-embedded (Cell-Id, E-CellID, OTDOA, UTDOA, etc.) and RAN-external (GNSS, Bluetooth, WiFi, terrestrial beacons, sensors, etc). The NR positioning shall exploit high bandwidth, massive antenna systems, network architecture/ functionalities (e.g. heterogeneous networks, MBMS) and deployment of massive number of devices. * MBMS: Multimedia Broadcast/Mukicast Service Additional NR positioning requirements include: 1. Support for different accuracy levels, latency levels and device categories 2. Support [1m] horizontal and vertical accuracy in [90%] of occasions 3. Reduced network complexity 3. Reduced device cost 4. Reduced device power consumption 5. Efficient signalling over the air interface and in the network 6. Support for hybrid positioning methods 7. Scalability (support for large nu

5G NR, 雖然被稱為New Radio, 但是他其實需要一整套新的核心網路作為搭配, 在3gpp的標準中, 稱為NGC (Next-Generation Core), (順帶一提, LTE網路中的核心網路稱為ePC, evolved Packet Core) 考慮到5G的進展, 以及NR和LTE的整合, 3gpp在設計NR時, 特別重視NR和既有LTE網路的整合, 我們可以看到下圖, 即為3gpp所探討的範例: 來自於:   http://www.zte.com.cn/cndata/magazine/zte_technologies/2017/2017_6/magazine/201706/t20170620_464364.html 其中, 沒有畫出來的Option 1, 為NR和LTE各自獨立營運, 而在所有的Option中, 除了Option 3之外, 都是以NGC作為整合的核心網路, 換句話說, 撇除過渡期的設計, 5G的核心網路應該是以NGC為主,

一開始, 我們先回顧一下甚麼是LTE (Long Term Evolution), 相較之前的3G以CDMA以及語音為主的電信服務, 當初在制定LTE時, (在WiMax的壓力下), 把telecom推進了一個未知的領域, 在4G, 或是LTE的架構下, 語音不再是通訊服務的唯一角色, 反而是資料傳輸, 應用, 即時影像成了網路服務的主流, 為了提供這樣的服務, LTE把背後的核心網路做了大幅度的改變, 如果我們不看接取技術, (從CDMA到OFDMA), 其主要的變化反而在於IP取代了原本的電話號碼, 成為主要的辨識單元, 也因此, 原本roaming, 或是資料庫的設計, 也就不那麼符合需要, 當時LTE的制定者們於是揮刀一砍, 重新設計一個更為簡潔的核心網路, 並命名為Long Term Evolution, 也應該是希望這樣的核心網路, 可以沿用許久, 然而, 從2005年至今, 12年後的現在, 大家也開始提出下一世代的無線網路架構, 也就是, New Radio (NR), 必須先說明的, 至少在目前, NR和5G是兩個相關但是不一樣的概念, 至少在5G的初期, 會是一種異質且拼湊的網路接取, 合併多種網路一起提供服務, 包括既有的LTE-A, WiFi (如同之前提到的LAA或LWA), 當然也包括NR, 如下圖所示: 來自:  http://www.edn.com/5G/4458325/What-is-5G-NR-

在LTE R14中, 另外加入了對於PRS廣播周期的調整, 對於特定TPs (transmission points) 而言, R14提供廣播周期的調整, 甚至可以保留特定的TP, 作為專屬用以定位的標竿, 高頻率, 甚至是連續的廣播PRS訊號, 考慮到之前所說的PRS的 分辨機制 , 以及small cell的架構, 在為了室內定位環境而設的極端架構下, LTE網路可以視為許多TP連續發送不同PRS訊號的網路, 這樣的網路架構, 可以提供近似於iBeacon的基礎建設, 並搭配TDoA的量測, 進一步增進定位的精確度. 來自:  https://blog.cubeacon.com/ibeacon-as-indoor-positioning-system.html

對於室內, 或者是城市中高樓密布的環境, 多通道效應 (multipath propogation) 一直都是定位的難題, 多通道效應是來自於發送端與傳送端之間有多個路徑, 換句話說, 接收端將由不同路徑得到多組來自於傳送端的訊號, 如下圖所示: 圖片來自:  http://www.ni.com/white-paper/6427/en/ 考慮到路徑不相同, 因此, 所量測到的到達時間也不同, 在ToA或是TDoA的定位模型下, 我們通常假設所量測到的到達時間是來自於直視路徑 (Light-of-Sight, LoS), 然而, 當使用者在室內移動, 接收來自於室外的大基地台 (macro cell) 訊號時, LoS的訊號不一定帶有最大的能量, 因此在回報時, 不一定被視為量測的目標, 以致無法正確找出LoS的到達時間, 也造成定位的誤差,

在原本OTDOA的架構中, Reference Signal Time Difference Measurement (RSTD) 用以量測兩個相鄰cell的時間差, 在原本架構中, RSTD的精確度為1 Ts, (Ts為LTE架構下的基本時間單位, 約為32ns, 可以參考: https://note-on-clouds.blogspot.tw/2015/12/lte-frame-time.html ) 考慮到此最小的時間單位, 我們所取得的量測誤差可以視為真實的時間量測誤差, 加上一個量化誤差(quantitation error), 因此, 直觀來說, 越精細的基本時間單位, 也就會有更精確結果. 我們可以從下圖中看到量化誤差的影響, 圖片來源:  https://www.ericsson.com/research-blog/indoor-positioning-enhancements-in-lte-standardization/

在原本LTE架構下, 定位的參考訊號 (PRS) 由eNB發送, 同時, UE可以接收其從屬eNB和相鄰eNB的PRS訊號, 作為計算OTDOA的基礎, 關於PRS的敘述, 可以參考 這一篇文章 , 然而, 為了識別來自於不同eNB的訊號, PRS以physical cell identifier (PCI) 作為辨識的基礎, 因此, PCI的分配, 也成了PRS的限制, 圖片來自:  https://www.ericsson.com/research-blog/indoor-positioning-enhancements-in-lte-standardization/ 在圖中, 同樣cell使用相同的PCI, 卻來自不同的天線 (TP) 尤其考慮在distributed antenna systems (DAS) 的架構下, 可能有不同的傳送點 (transmission points, TPs) 分享同樣的PCI, 考慮到不同的TP就代表不同的位置, 其所代表的TDOA, 也就含有不同的資訊量, 如果我們可以辨識越多的TDOA來自於不同的TP, 很明顯的, 就可以增進LTE在定位上的精確度, 此時, 要怎麼辨識來自於不同TPs的PRS就是一個問題,

在 之前的文章 中, 我們討論了在LTE下的定位技術, 當時, 仍停留在技術的討論, 尚未修改spec, 隨著時間的經過, 3gpp也對LTE的定位做出更多改變, 正好看到一篇文章討論最近LTE架構下的定位技術演進: https://www.ericsson.com/research-blog/lte/indoor-positioning-enhancements-in-lte-standardization/ 接下來應該會花一些篇幅翻譯這篇文章, 並補充一些相關的了解. 原本文章來自: Ericsson Research Blog

在之前LAA的介紹中, 我們提到了LBT (Listen Before Talk) 的技術, 事實上, 在先期的LAA的標準中 (LTE-U), 一開始並不包括LBT, 直接把5GHz的頻譜, 用CA的技術整合入LTE網路使用, 然而, 由於歐盟和日本對於ISM頻帶的要求, LTE開始討論LBT的技術, 並在R13加入標準, 圖片來自: https://www.qualcomm.com/invention/technologies/lte/laa

在 之前的文章 中, 我們除了介紹LWA的技術, 也提及了在LTE架構下的另一種技術, LTE-U, 也就是LAA (Licensed Assisted Access), 和LWA不同, LAA並不使用WiFi的通訊技術, 而是只使用WiFi的5GHz頻帶, (事實上是 ISM頻帶 , 可以非授權使用), 雖說, ISM頻帶本身沒有對使用者設下限制, 但是也因此, 使得在ISM頻帶上的通訊技術都十分強調抗干擾的功能, 不論是對於本身網路的干擾(例如: WiFi AP之間的干擾), 或是, 不同通訊技術之間的干擾(例如: WiFi AP對藍牙裝置的干擾), 同時,也對使用的傳送功率走一定的限制, 避免使用者以蓋台的方式, 獨佔ISM頻帶的通訊資源,

在之前一系列的文章中, 介紹了LWA和LWIP兩種結合WiFi和LTE傳輸的技術, 因此, 在最後一篇文章中, 將介紹LWA和LWIP的比較, 事實上, 在3gpp介紹LWA和LWIP的投影片中, 最後一頁也是LWA和LWIP的比較表格, 我們先來看看雙方的差別: 根據表格, 我們可以看到LWA和LWIP都是由eNB開始, 同時支援WiFi網路的訊號量測, 用以決定mobility set, 而LWA提供了和3gpp更緊密的整合, 包括對於同一個資料流的封包匯流, flow control機制, 以及快速認證機制, 但對WiFi網路架構有較多的修改, 至於LWIP則可以和既有WiFi網路結合, 直接提供上行和下行傳輸, 但是由於缺乏和LTE的協調機制, 在傳輸效能上應該較LWA差,

接續之前 文章 的說明, 在這一篇文章中, 我們將介紹LWIP的流程, 對於LWIP而言, 整體程序大概分成以下階段: 確認LWIP是否可以使用 (1~4) 進行訊號品質的量測, 並決定mobility set (5~8) UE和WiFi AP建立連線, 取得IP, (9~14) 透過IP建立LWIP連線, 並維持參數更新 (15, 16) 在括弧中的標號對應於下圖的流程圖, 其中, 一開始LWIP能力確認, 只需要執行一次, 其他部分, 由於資料處理都由tunneling決定, 並沒有太多特殊的資料流程.

在 上一篇文章 中, 談到了LWIP的架構, 接下來, 我們來看看其control plane和data plane的設計, 和LWA使用3gpp定義的 LWAAP 進行封裝不同, LWIP的封包完全走IP層協定, 這樣的設計, 可以讓LWIP快速普及, 並重複利用IP的設計, 但同時, 也繼承了IP網路的缺點, 例如: DDoS攻擊 , 對於行動網路來說, 若是其中主要節點, 如eNB, 受到攻擊, 可能會癱瘓部分行動網路, 造成龐大影響, 同時, 也無法使用大量的備援機制, 來抵抗DDoS攻擊, 因此, 在LWIP的設計上, 就多加入一個新的節點 (LWIP-SeGW), 用以保護eNB的IP位址, 防止DDoS的攻擊, 來自:  http://www.3gpp.org/images/PDF/2016_03_LWA_LWIP_3GPPpresentation.pdf 換句話說, 對於UE而言, 以為是在和LWIP-SeGW進行連線, 而LWIP-SeGW就是eNB的代理人, 負責轉傳所有訊息,

在之前 一系列文章 中, 介紹了LWA的架構, 然而, 光是只有LWA, 只完成了把資料透過LTE和WiFi介面送到UE, UE還必須要把來自於LTE和WiFi的訊號, 匯整起來, 上傳到同一個應用程式, 而不能夠分屬不同的連線, 因此, LWA使用GTP Tunnel來完成資料的匯整, 使同一應用程式可以收到不同連線的封包, 在3gpp架構中, LWA所處理的問題也可以由LWIP來完成, LWIP的全名是: LTE WLAN Radio Level Integration with IPsec Tunnel, 其中關鍵字在於: IPsec Tunnel, 也就是: IP Security Tunnel, 根據 Wiki的解說 , IPsec Tunnel會將原本的封包加密後, 再加上一組新的IP位址, 來自:  http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/IPSec_Over.html 而在LWIP中, 將eNB和UE之間的連線使用IPsec Tunnel來傳送, 換句話說, 透過WiFi要傳送給UE的封包, 將再包裝一層屬於WiFi網路的IP header, 傳送給UE,

在 LTE 系統中, 使用 TDoA (Time Difference of Arrival) 作為定位的一種方法, 詳細關於 TDOA 用來定位的方法可以參考 這一篇文章 , TDOA 用以定位, 每一對基地台可以得到一組雙曲線, 取雙曲線的交點, 我們可以得到 UE 的位置資訊, 如下圖所示: 來自於:  http://scialert.net/fulltext/?doi=jas.2014.1564.1569&org=11 事實上, 另一種更直觀的定位方法是使用 ToA (Time of Arrival) 進行定位, 此時, 我們會得到到以基地台為圓心的多組圓, 取其交點, 即為定位結果, 來自於:  https://www.gitbook.com/book/hom-wang/indoorpositioning-ls/details 至於為什麼在 LTE 系統中要使用 TDoA, 而非 ToA, 通常來說, 我們都會說這是因為 TDoA 對於同步要求較低.

在之前一系列的 文章 中, 介紹了LTE LWA的架構, 其中, 有一個重要的介面, 就是Xw介面, 來自於:  http://www.sharetechnote.com/html/Handbook_LTE_LWA.html 如先前 文章 所敘述, Xw主要是負責eNB和WT的溝通, 尤其是當WiFi AP不和eNB共構時, Xw就成了必需的介面, 如上圖右所示, 和其他3gpp系列的協定類似, Xw一樣分成兩個部分: 分別對應於控制層 (Xw-C) 和資料層 (Xw-U), 分別處理資料傳輸以及控制訊號交換.

在上一篇 文章 中, 我們介紹了LWA的架構, 接下來, 我們會進一步討論LWA的資料交換流程, 在3gpp的投影片中 (pp. 16), 附上了LWA的資料流程如下圖: 來自: http://www.3gpp.org/images/PDF/2016_03_LWA_LWIP_3GPPpresentation.pdf 在圖中, 我們可以把資料流程分成6類: 1,2:  宣告對LWA的支援 3-6:  對於WiFi網路的量測 7-10:  eNB對於WT的設定 (WiFi AP透過WT得到設定) 11, 12:  UE找到對應的WiFi AP並完成WiFi網路連線的建立 13:  開始LWA的資料連線 14-16:  對於網路進行量測以及設定更新

在上一篇 文章 中, 我們提到了LWA是藉由eNB的能力整合WiFi和LTE網路, 接下來, 我們將介紹LWA的資料網路 (data plane) 和控制網路 (control plane) 的細節, 資料網路 (data plane) 和控制網路 (control plane) 的差別在於, 資料網路中, 傳輸的是真正封包中的資料, 而在控制網路中, 傳送的則是網路節點的控制訊號, 以有線電話為例, 資料網路傳輸說話的語音, 而控制網路則傳輸每個交換器的控制訊號, 把語音傳給正確的用戶, 在LTE LEA架構下的資料網路如下: 來自:  http://www.3gpp.org/images/PDF/2016_03_LWA_LWIP_3GPPpresentation.pdf 這樣的架構如同之前文章中提及, LWA基本上沒有對WiFi的MAC層進行修改, 而利用LWAAP (LWA Adaptation Protocol) 轉譯LTE的連線資料 (稱為bearer) 到WiFi的網路中, 由於資料是由eNB進行分配, 因此在R13中, 只牽涉downlink LWA, 所有uplink的資料都仍是透過LTE網路傳輸,

在 上一篇文章 中, 我們介紹了LWA的基本功能, 但是對於通訊系統而言, 更重要的是如何完成這些功能, 根據3GPP的 官方文件 , 我們可以看到LWA有以下特色: Allows aggregating LTE and WLAN at RAN level WLAN AP/AC only interacts with the LTE eNB; no interaction with LTE Core Network Key drivers: performance, mobility, eliminating need for WLAN-specific Core Network nodes LWA is controlled by E-UTRAN Node B(eNB), based on User Equipment (UE) measurement reporting 其中, LWA主要的特色是LTE和Wi-Fi的整合是在於RAN (Radio Access Network), 並不牽涉到core-network (核心網路) 的工作, 這樣的架構就不同於Multipath TCP (MPTCP) 的架構, 在MPTCP中需要為Wi-Fi網路設定一個特殊的代理人 (MPTCP proxy), 同時, 在P-gateway外就進行資料的分流, 直到UE才用MPTCP匯合 (下圖右下表示), 來自於:  http://www.netmanias.com/en/post/reports/8532/laa-lte-lte-u-lwa-mptcp-wi-fi/analysis-of-lte-wifi-aggregation-solutions 相較MPTCP, LWA (左下圖) 則在基地台 (eNB) 分流, 並不需要額外的核心網路元件, 來進行Wi-Fi存取的管理,

原本是打算要繼續寫LWA的議題的, 卻發現關於LTE的許多基本概念沒有說清楚, 這樣在後續說明中, 會出現許多問題, 比如說, 假如不知道PDCP層的功用, 就無法了解在LTE架構下如何將來自於LTE和Wi-Fi的封包匯合, 因此, 在此先介紹LTE的分層以及其核心網路 (core-network) 的架構, 做為未來說明的基礎知識. 對於一個從電腦網路 (datacom) 出身的學生, 我們非常習慣OSI的7層網路架構, 尤其是: PHY (e.g., ethernet), MAC (e.g., TCP), network (e.g., IP), application, 因此, 對於一開始接觸LTE這種從telecom演變而來的網路時, 有時候會被其中的名詞混淆概念. 來自於:  http://www.netmanias.com/en/post/techdocs/5904/lte-network-architecture/lte-network-architecture-basic 在LTE網路中, 無線接取部分 (圖中的UE和eNB界接處), 分成4個子層: PDCP, RLC, MAC, PHY. 其中, PDCP, RLC, MAC這三層都屬於OSI架構中的第二層(Layer 2).

關於OpenStack Sahara, 其中還有一個特點, 就是Elastic Data Processing (EDP), 根據 OpenStack文件 上的敘述, EDP被定義為: Sahara EDP uses a collection of simple objects to define and execute jobs. These objects are stored in the sahara database when they are created, allowing them to be reused. This modular approach with database persistence allows code and data to be reused across multiple jobs. The essential components of a job are: executable code to run input and output data paths, as needed for the job any additional configuration values needed for the job run 根據上述定義, EDP是一種工作 (job) 管理的架構, 藉由Sahara database, 同時重複利用執行的程式以及被處理的資料,

對於一個通訊系統而言, 若是要增加傳輸量, 有以下三個指標: 傳輸技術, 使用頻寬, 訊號品質, 其中, 最直接的想法, 就是增加所使用的傳輸頻寬, 就像是增加高速公路的寬度一樣, 自然可以容納更多的車子行走, 然而, 頻寬作為公有財, 被國家 (NCC) 與國際組織 (ITU) 所管理, 所以之前會看到中華電信用256.85億元標下4G頻段的新聞, 考慮到頻寬如此稀少和昂貴, 3GPP就把主意放到ISM band上, 想要把開放公眾使用的頻譜用來擴充LTE的傳輸頻寬, 目前, 有以下兩種方法: LTE-U, LTE-H (來自: http://blog.3g4g.co.uk/2015/04/lte-hetnet-lte-h-aka-lte-wi-fi-link.html ) LTE-U是在ISM band上直接傳輸LTE的訊號, 並設計一種特有的頻譜共享機制, 和Wi-Fi一起競爭5GHz的通訊頻帶, 所收到的兩個不同頻帶訊號在手機上在合成為一個訊號, 雖然, LTE宣稱其設計的機制能比Wi-Fi更有效率, 但也面臨Wi-Fi陣營的抵制與挑戰, 因此, 3gpp只好重新設計另一個方案, 使用Wi-Fi的無線接取技術, 來化解Wi-Fi陣營的阻力, 這個方案稱為LTE-H, 也就是今天要討論的LTE Wi-Fi Link Aggregation (LWA).

在進一步介紹Sahara之前, 我們要先了解hadoop的設計原理, hadoop是一開始雲端的平行運算平台, 基於Google提出的MapReduce架構所設計, 在一開始雲端的環境中, 儲存的虛擬化比較成熟, VM的概念並不盛行, 因此, hadoop是基於實體機的架構進行設計, 在hadoop的架構下, 分成兩個主要的部份: HDFS, 一個分散式資料儲存系統; MapReduce: 基於HDFS的平行運算, (來自: https://cvw.cac.cornell.edu/MapReduce/locality ) 在上圖中, 藍色方塊代表HDFS中的資料鏡像, MapReduce基於資料鏡像的位置, 進行資料的運算, 也就是所謂: 搬程式不搬資料 , 這樣的架構假設了資料大小遠大於程式, 適合於大資料平行化處理, 考慮到硬碟的讀取速度, 通常要至少大於1TB的資料較有效率, 注意: hadoop事先設計HDFS, 在設計基於HDFS的平行運算架構, 因此, MapReduce的平行運算天生就是為了處理大資料, 容錯, 以及實體機而設計, 基於這樣的先天設計, hadoop適用於TB以上的資料平行運算, 本身自帶容錯機制, 而且對於運算資源的調控極為笨拙.

蒙提霍爾問題，亦稱為蒙特霍問題或三門問題（英文：Monty Hall problem），是一個源自博弈論的數學遊戲問題，大致出自美國的電視遊戲節目Let's Make a Deal。問題的名字來自該節目的主持人蒙提·霍爾（Monty Hall）。 這個遊戲的玩法是：參賽者會看見三扇關閉了的門，其中一扇的後面有一輛汽車或者是獎品，選中後面有車的那扇門就可以贏得該汽車或獎品，而另外兩扇門後面則各藏有一隻山羊或者是後面沒有任何東西。當參賽者選定了一扇門，但未去開啟它的時候，知道門後情形的節目主持人會開啟剩下兩扇門的其中一扇，露出其中一隻山羊。主持人其後會問參賽者要不要換另一扇仍然關上的門。問題是：換另一扇門會否增加參賽者贏得汽車的機會率？ (以上敘述和圖片都是來自維基百科： https://zh.wikipedia.org/wiki/%E8%92%99%E6%8F%90%E9%9C%8D%E7%88%BE%E5%95%8F%E9%A1%8C )

OpenStack中的Sahara專案是為了提供OpenStack平台快速布建hadoop服務, 為了瞭解Sahara, 我們要先了解hadoop是甚麼, 以hadoop 2.0為例, hadoop提供的運算平台有以下三種特色: 以資料為基礎的計算架構, 也就是MapReduce 資料備份與提取機制, HDFS, 用以處理雲端節點故障的錯誤 在YARN(hadoop 2.0)中, 則加入了運算資源調度的功能 雖然hadoop原本設計給實體機作為雲端運算平台, 但對於IaaS架構而言, 利用VM提供hadoop架構有以下好處: 通常一個hadoop cluster只會提供一種特殊應用, 在有多個cluster下, VM可以減低管理cluster的麻煩 對於早期布署與小規模應用, IaaS提供一個友善的環境發展演算法與scaling機制 考慮到以上好處, OpenStack有Sahara計畫支持hadoop在OpenStack上的布署, 同時, 在其他公有雲平台, 如Amazon和Azure都有提供相對應的服務, 提供使用者一個快速布建與測試hadoop cluster的服務,