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 另一方面, 對於 ...

對於一個通訊系統來說, 同步是一個重要, 但是常常被忽略的問題, 大致上的原因就是因為同步的研究已經發展久遠, 相關的技術也都成熟, 然而, 考慮到一個以排程為基礎的通訊系統, 使用者裝置 (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