Castle on a Cloud

對於一個通訊系統來說, 同步是一個重要, 但是常常被忽略的問題, 大致上的原因就是因為同步的研究已經發展久遠, 相關的技術也都成熟, 然而, 考慮到一個以排程為基礎的通訊系統, 使用者裝置 (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的文件中, 卻有一種像是剪貼簿的感覺, 只是把各家報告複製貼上, 而缺乏整合...