Castle on a Cloud

在 UE 移動時，將會定期得知連線 (serving) eNB的訊號強度，若是小於一定數值 (Ssearch_intra)，則開始進行相鄰基地台 (target eNB) 的訊號強度量測 (Inter-neighbor measurement)。等到相鄰基地台的訊號強度比起服務 eNB 好上一定的數值 (Qhyst) 且持續一定時間 (Treselect)，才進行換手。其中，我們可以把流程列如下圖。 圖一、Reselection的門檻與流程 在進行 Inter-neighbor measurement 後，UE 將根據 S-criteria 找出可用的 (suitable) 基地台，並根據 R-criteria 找出最佳的基地台，假如最佳的基地台不是服務的 (serving) eNB 則進行換手。 S-criteria 和 R-criteria 可以藉由調整參數變化，舉例來說，Qhyst 就是在 R-criteria 中的參數，用來提升服務的 (serving) eNB 的優先權，避免由於訊號的通道遮蔽效應 (shadowing effect) 或是衰減 (fading) 所造成的暫態訊號變化影響換手。Treselect 則要求此訊號差值維持一段時間，若是未達 Treselect 則重新計時，這是用來避免比如說 UE 在兩個 eNB 邊緣之間游移所造成的高頻率換手，或者，我們也稱之為乒乓效應 (ping-pong effect)。 Qhyst 和 Treselect 的設定，事實上是換手次數與 UE 訊號品質的權衡 (trade-off)，較高的 Qhyst 與較長的 Treselect 將減少換手次數，但是 UE 必須忍受較低的訊號品質，且有因為訊號強度而斷線的風險。較低的 Qhyst 與較短的 Treselect 則提供較高的訊號品質，但是頻繁的換手，造成系統的負擔以及 UE 因為換手產生的延遲。

LTE Measurement Gap 是用以量測周圍基地台的訊號強度，藉以決定是否進行換手 (handover) 的基地台選擇。對於在相同頻帶 (intra-band) 一樣是LTE的訊號，只需要切換時間就可以進行量測，對於跨頻帶 (inter-band) 或是跨通訊系統 (inter-RAN) 的訊號量測，就需要 UE 硬體電路對於相對應的中心頻率 (center frequency)、頻寬 (bandwidth) 等硬體參數進行設置。 由於成本以及體積考量，在一個終端通訊裝置當中，通常所有共模的通訊晶片都共用相同的無線通訊模組 (RF module)，因此，在裝置設定與切換就需要保護時間 (guard time) 的設計，讓硬體能夠順利切換。在LTE標準 (TS 36.133) 中，提供兩種不同的設定值，分別是 GP 0 和 GP 1，如下表所示。 表一、Gap Pattern in LTE Network 當 UE 在 Measurement Gap 中時，eNB 不會和 UE 建立任何通訊，因此，UE 可以跳至目標頻帶與通訊系統進行訊號強度的量測，並在 Measurement Gap 結束後，跳回原有 eNB 進行傳輸。 考慮到不間斷的傳輸，因此，UE 和 eNB 必須先溝通好 Measurement Gap 的起始時間、長度與重複區間，這些資訊與參數透過 RRC Reconfiguration 中的 MeasGapConfig 進行設定。 其中，計算的方式如下所示：  SFN mod T = FLOOR (gapOffset/10);  Subframe= gapOffset mod 10;  where T = MGRP/10   其中，gapOffset、MGRP定義於表一。  SFN (System Frame Number) 則代表每一個frame的編號。

在通訊系統中，對於閒置的 UE，不太可能透過排程給予通訊資源。因此，當 UE 要和 eNB 建立連線時，就必須使用 Random Access Procedure (RAP)。在 LTE 中以下狀況需要藉由 RAP 取得通訊資源。 從 RRC idle 要初始化進行傳輸 RRC 連線的重建 UL 時，RRC 連線不同步或是沒有 PUCCH 資源 DL 進行時，UL 連線消失 換手 (Handover) 需要 Timing Advance 資訊 (定位需求) RAP 可分為競爭式 (contention-based) 或是非競爭式 (contention free)，競爭式 RAP 是由 UE 端發起對於 Preamble 的競爭，而非競爭式 RAP 則是 eNB 指派固定範圍的 Preamble，程序如下圖。其中，上述六種狀況中，前三種只能用競爭式，後三種可以用非競爭式，考慮到有限的 Preamble 位址，通常只有 Handover 進行非競爭式 RAP。 圖、RAP的流程 (http://xdxdd.blogspot.com/2012/08/lte-random-access-procedure.html) 非競爭式 RAP，Preamble 的位址直接由 eNB 指派，在競爭式 RAP 中，UE 根據所得到的系統資訊，從 64 個 Preamble 位址選一個出來競爭 (Msg1)，若是發生碰撞，則進行 backoff，若是成功，eNB 得知 UE 資訊，並且回覆 Random Access Response (RAR) 給 UE (Msg2)，其中，包含了TA (Timing Advance) 的資訊，用以同步 UE 與 eNB 間上行資料的傳輸時間，暫時的識別符號(Temporary C-RNTI)，以及上行通道資源 (UL Grant)。UE 收到 RAR 後，將把帶 UE 資訊的 ID 在 UL Grant 上傳，若是沒有其他 UE 在 Msg1 使用相同的 Preamble，UE 就競爭到 RAP 的通訊資源。

在UE開機後，要先藉由 PLMN 和 Cell Selection，選擇要使用的 eNB，並聽取 eNB 的系統資訊 (System Information，SI)，完成 UE 和 eNB 之間的同步。在 PLMN 和 Cell Selection 過程中，UE 會去聽取相鄰 eNB 的訊號、SI 以及訊號強度，並根據上述資訊選擇一個可以使用且訊號品質夠好的 eNB 進行 Attach Procedure。 圖一、Initial Access Procedure Attach Procedure 又分成以下動作： 先藉由 Random Access Procedure (RAP) 取得上傳資源(不在下圖中)，完成 RAP 後，UE 將送 RRC 連線需求以及 Attach Request (紅框)。 eNB 收到上述資訊，將把這些資訊送到HSS進行使用者認證的程序，並且將認證結果回覆eNB 和 UE，並且根據認證資訊，建立起加密訊息 (藍框)。 確認認證成功後，MME 主動和 S-GW 透過 GTP (GPRS Tunneling Protocol) 建立 Default Bearer，讓 UE 有封包傳送能力。之後，MME 將 Default Bearer 的訊息和 Attach Accept 訊息透過 eNB 傳送給 UE，此時將使用 GUTI 取代原本通訊時使用的 IMEI，保護 UE 的資訊。UE 將根據重新配置 RRC，包括：SRB1、SRB2 及 DRB，完成後，eNB 告訴 MME 關於 RRC 的設定完成(綠框)。在下圖中，省略了 eNB 和 UE 的封包傳輸中，連線能力的確認 (Capability Information) 以及加密模式的確認。 最後，UE傳送 Attach Complete，完成 Attach Procedure 流程，此時才可以啟用 Default Bearer。(橘框) 圖二、Attach Procedure 建立完 Default Bearer，接著要建立 Dedicated Bearer。建立 Dedicated Bearer 是在 UE 提出需求後(藍框)，由 MME 發起，由於已經有 Default Bearer 連線，因此，不必再有認證程序。主要的步驟重複在建立 D

資料傳送時會發生什麼樣的狀態轉變? 要如何解決上行傳送的問題? 對於 UE 而言，RRC (Radio Resource Control) 有兩種狀態，分別是：RRC_IDLE 以及RRC_CONNECTED。在 RRC_IDLE 的狀態下，UE 連上 LTE 系統並註冊，但是並沒有連線，此時，UE 會接收來自 eNB 的 paging (呼叫) 的訊息，用以得知接收下載的訊息，同時，UE 也會量測相鄰 cell 的訊號強度。在 RRC_CONNECTED 時，UE 建立 RRC 連線，此時，UE 除了 RRC_IDLE 時所要進行的量測外，還必須聆聽 Control Channel 上的訊息，並回報量測到的訊號品質 (channel quality)。 在 RRC_RRC_CONNECTED 下，又分成兩個狀態：OUT_OF_SYNC 和 IN_SYNC。由於尚未完成同步，UE 在 OUT_OF_SYNC 狀態下，只能夠接收下載資料，而不能夠上傳任何資訊。在 IN_SYNC 的狀態下，UE 可以進行資料的上傳與下載。若是過久沒有上傳資料，UE 的狀態將從 IN_SYNC 進入 OUT_OF_SYNC，此時，若是要重新進入 IN_SYNC 狀態，則必須重新進行 Random Access Procedure ，取得上傳資源，並進行同步。 上圖是 RRC 的狀態轉換圖，其中關於轉換的觸發條件列在下方： 建立 RRC 連線 釋放 RRC 連線 Random Access Procedure 過久沒有上傳資料

3GPP LTE 比較於 3GPP Release 6 HSPA 在 RLC AM 和 HARQ上有什麼優勢? LTE HSPA 在 LTE 中，RLC 和 HARQ 都在eNB 上實作，可以有更緊密的互動。 在 HSPA 中，雖然也引入了 HARQ 的機制，但是 RLC 重傳的機制在 RNC (Radio Network Controller)上實作，導致較高的延遲。 若有一即時視訊影像傳輸需用 LTE 傳送，具備服務品質需求 Delay bound=300ms，Packet loss ratio≤10-4，請說明從 TCP/IP 層 (TCP/UDP)、RLC 層 (AM/UM) 到 MAC 層 (HARQ) 應該選用什麼樣的重傳機制組合?並說明為什麼?  RLC (Radio Link Control) 在 MAC 層之上，其主要目的有三：確保封包順序、移除重覆封包與重傳、封包的切割與重組。在這裡，我們將專注於 RLC 層中封包的重傳機制。在 RLC 層中分成三種操作模式： Acknowledged Mode (AM) Unacknowledged Mode (UM) Transparent Mode (TM) 其中只有在 AM 下，RLC 對封包進行重傳。 重傳封包可以降低錯誤濾，但是將增加資料傳送的延遲。考慮到不同服務中，封包的延遲與錯誤率限制，我們可以把各種服務的適用性製作如下表： Delay long short Channel (error rate) good bad good bad RLC AM ON ON OFF Cond. ON HARQ X X ON ON 由於上表只列出了相對應的比較，為了瞭解一個服務在 LTE 網路中延遲和錯誤率的相對應關係，我們列出 LTE 網路中各項服務的 QoS 要求列表如下： LTE QCI Resource Type Priority Packet Delay Budget Packet Error Loss Rate Example Services QCI-1 GBR 2 100ms 10 -2 Conversational voice QCI-2 4 150ms 10 -3 live streaming of conversational voice QCI-3 3 50ms Real time ga

LTE Frame Structure中 T f =10ms其數值背後的依據為何? 在 LTE 系統中，使用 OFDMA 作為調變技術，其中，每一個子載波(sub-carrier)的頻寬為15kHz。考慮到 FFT 最大的取樣數值為 2048 點， T s 為每一個 FFT symbol 的時間間隔。 T s = Time Unit = 1 5kHz×2048 接著，我們把 15360 個 T s 當作一個 T slot ，因此 T slot 的長度為 0.5ms。 T slot = 15360× T s = 0.5ms 對於 OFDMA 系統而言，必須要有 cyclic period (CP) 來保護所傳送的訊號，減少訊號之間的相互干擾。在 T slot 中，也就是一個 sub-frame (slot) 中，定義了 CP 和傳送信號的時間分佈，其中，第一個 CP 長 160 個 T s ，其他的 CP 長為 144 個 T s ，而一個 OFDM symbol 長 2048 個 T s 。因此， 160+2048×7+144×6=15360 。 20 個 T slot 作為一個 T f ，也就是10ms。其中，每兩個 T slot 又被稱為一個 T subframe ，時間長度為1ms，也是在LTE系統中，排程 (scheduling) 的基本時間單元。 T f = 20× T slot = 10 ( ms ) , T subframe = 2× T slot = 1 (ms) 下圖是LTE中，各時間單位的相關性，圖片取自於3GPP TS 36.211文件的Figure 4.1-1。關於frame的結構和時間定義主要敘述於該文件的第四節。 Figure 4.1-1: Frame structure type 1 (TS 36.211) 在 TD-LTE 中，額外定義了 half-frame 的時間單元，每一個 half-frame 是 5ms，包含 10 個 T slot 。因此，在一個 frame time 中，有 2 個 half-frame。考慮到硬體在傳送和接收上共用同一個射頻電路，因此，在 TDD 模式下為了硬體的切換時間，在 TDD-LTE 中，使用了 T slot 作為保護區間 (Gua

在OpenStack kilo版本中, 提出了Magnum的支援, 不同於前述的Heat和Nova嘗試在既有的架構下結合docker的方式, Magnum是一個通用的容器管理解決方案,  支援Kubernetes和Docker, Magnum為了結合既有的OpenStack支援, 以及docker特有的叢集(Swarm)部屬方式, 而擁有以下的特點[4]: Magnum在任何需要管理容器的地方, 使用其他的OpenStack元件, 例如: Nova, Heat, Neutron, Glance和Keystone Nova用於創建輕量的虛擬機(micro VM), docker容器在虛擬機中運行 Heat用於整體資源調度, 對於docker, Heat則會創建docker Swarm叢集以及Swarm Agent Magnum創建bay-model(叢集模型), bay(叢集)以及容器的創建

嚴格上來說, docker和OpenStack是兩種不同的服務, OpenStack提供的是虛擬機(Virtual Machine)的調度與管理, docker提供的是容器(Container)的封裝與隔離機制, 然而, 對於一般使用者而言, 兩者皆提供一種獨立的, 可擴充的運算資源, 因此, 也有許多比較文章[7], 嘗試比較docker和OpenStack適用的範圍. 事實上, OpenStack也開始思考如何結合docker的運算架構, 提供容器作為一種服務(Containers-as-a-Service) [1, 2], 在OpenStack中, 有三種不同的方法和docker結合: Nova中的Docker driver [1], heat中的Docker driver以及Kilo版中推出的Magnum Project [2]. 主要的差異在於容器開啟的位置是實體機(physical machine)還是虛擬機.

在這一篇文章中, 將介紹一些docker所使用的技術, 相同的, 由於docker的相關技術已經被討論許多, 也有取多trace code, 在文章中, 只大略提及個技術的重點與限制, 並列出相關文件於參考資料作為延伸的閱讀. docker是藉由Linux Containers (LXC)技術作為基礎, LXC包括兩個部分: Linux Namespace (chroot)以及Linux CGgroup, chroot提供了一種簡單的隔離模式: chroot內部的檔案系統無法訪問外部的內容 Linux Namespace在此基礎上, 提供了對UTS (UNIX Time-sharing System), IPC (interprocess communication), mount (檔案系統), PID (處理程序), network, User等的隔離機制. 簡單來說, LXC藉由遮蔽PID, 提供分離的操作環境, 因此, docker的每個容器都有獨立的檔案系統, 處理程序ID, 以及多工架構,

在這一系列文章中, 將介紹docker這一種虛擬化技術, docker作為一種作業系統層虛擬化技術, 在網路上已經有大量的討論, 因此, 在文章中, 只簡短的總結一下個主題的結論, 並且附上連結作為進一步了解的參考. 在進入細部介紹之前, 我們先介紹docker [1]: Docker is an open platform for building , shipping and running distributed applications. It gives programmers, development teams and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications. 在官方的介紹中, 說明了docker的三種功能:  building ,  shipping  和  running 其中, building是建立docker的環境, shipping則是docker容器(container)的搬移, running則是docker容器的執行.

在 上一篇文章 中, 我們介紹了MaaS, 若以雲端的三種服務類型分類(IaaS, PaaS, SaaS), MaaS提供一組實體的伺服器叢集, 應該被歸類於IaaS的服務類型. 當我們定義好一個運算支援叢集, 不論其運算資源是來自於虛擬機(例如: Amazon, OpenStack), 或是實體的伺服器群組(例如: MaaS), 都必須要部件相對應的作業系統與程式, 提供叢集內運算或是管理的需求, 以hadoop 1.2.1為例, 運算節點就分成了master和slave, 其中, master節點必須以heart beat的方式控管從集中的節點, 並根據即時的叢集狀態, 進行工作(MapReduce)與儲存(HDFS)的分配. 對於更複雜的叢集, 如OpenStack, 就擁有更多不同的角色與設定, 因此, ubuntu JuJu的目的就在於提供一套映象檔(image)與叢集設定的機制, 使得雲端上的叢集, 可以快速且自動地在運算叢集上建立起服務.

甚麼是MaaS? MaaS的全名為Metal as a Service, 其中, Metal為Bare metal, 所指的是不帶作業系統的伺服器硬體. 考量到一個資料中心的使用環境, 當管理者必須管理數以百台,甚至千台實體機器(physical nodes), 如何將這些伺服器組件起來, 變成像是hadoop或是OpenStack的叢集提供雲端服務就成了一個棘手的問題. 為了解決這樣的問題, Canonical (ubuntu的母公司) 提出了MaaS的解決方案. 透過MaaS, 管理者可以透過web介面或是API進行叢集 (cluster) 間的資源配置, 例如說, 配置一台至少有16G記憶體的伺服器, 作為hadoop叢集的資料節點. 此功能從ubuntu 12.04版本時開始支援, 提供一些預先設定的內容, 讓安裝好後的Linux作業系統能和既存的服務叢集相容. 考慮到MaaS和伺服器網路的關聯性, 對於MaaS管轄下的伺服器叢集的網路介面 (例如: DHCP和DNS), 都必須歸MaaS管轄, MaaS管轄的單元為伺服器叢集, 在叢集中, 伺服器扮演不同的角色, 以OpenStack為例: 至少包含了Control Node, Network Node以及Compute Node. 藉由監控這些節點的負載, MaaS可以平衡一個雲端服務叢集所需要的資源, 並動態配置, 增進資料中心的能源使用效率.

在hbase中, 有些時候我們須查詢某一欄位的數值是否更新, 在這個情況下, 應該如何利用hbase shell的方式查詢呢? 如果我們確知row-key的名稱, 我們可以利用get的方式執行: hbase(main):005:0> get 'UserTable', 'B8:8D:12:1A:59:76' [...] 10 row(s) in 0.4240 seconds 甚至指定欄位, 例如: hbase(main):008:0> get 'UserTable', 'B8:8D:12:1A:59:76', {COLUMN=>['x', 'y']} COLUMN                CELL  x:                   timestamp=1434519293316, value=12.847539358614743  y:                   timestamp=1434519293316, value=28.36858703324554 2 row(s) in 0.0100 seconds 然而, 若是row-key為自動產生 (由寫入程式決定),  或是, 不知道row-key的資訊 (例如: 使用者的MAC位址), 應該如何查詢呢?

對於hbase而言, 若是發生無法挽救的錯誤, 導致需要重新啟動hbase叢集, 一直以來都是麻煩的事情... 尤其, 這還牽涉到HDFS的資料同步, 因此, 若是要重新格式化hbase叢集需要經過以下步驟: 1. 關閉hbase (注意HMaster, 可能會沒有回應...) 2. 關閉hadoop 3. 清除各節點上hbase和hadoop的資料 4. 格式化hadoop namenode 5. 啟動hadoop 6. 啟動hbase 由於目前所使用的雲端環境不是非常穩定, 有時會所有虛擬機同時重新啟動, 導致hbase叢集也必須重啟... 因此, 我在hbase master節點上寫了一支shell script, 把重啟hbase叢集自動化執行 以下是一些環境變數: hbase 叢集節點: hbasemaster, hbaseslave01, hbaseslave02 HDFS資料儲存位置: /opt/data hadoop log儲存位置: /opt/hadoop/logs hbase資料暫存位置: /opt/hbase/hbase-data hbase資料暫存位置: /opt/hbase/hbase-logs 安裝hadoop和hbase的權限: hduser (這些變數的設定請參考hadoop和hbase的安裝) 以下是shell script檔 (restart_hbase.sh): #!/bin/bash # Program: #       This program restarts hbase cluster. # History: # 2015/06/11     Chun-Hsien Ko     First release PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:~/bin export PATH pid=$(su - hduser -c "cat /opt/hbase/hbase-pids/hbase-hduser-master.pid") echo $pid kill -9 $pid su - hduser -c "/opt/hbase/b

要存取hbase, 最簡單的方法就是透過hbase shell, hbase shell是hbase內建的存取介面, 透過即時的命令輸入, 可以操作hbase中資料表的操作, 我們以hbase 0.94版本為例, 介紹hbase shell的功能: 首先, 我們先確認hbase和hadoop的程式都仍在執行, 接著, 進入hbase的路徑(/opt/hbase), 進入hbase shell: $ /opt/hbase/bin/hbase shell 進入hbase shell後, 我們先輸入help查看說明: hbase(main):003:0> help HBase Shell, version 0.94.2, r1395367, Sun Oct  7 19:11:01 UTC 2012 Type 'help "COMMAND"', (e.g. 'help "get"' -- the quotes are necessary) for help on a specific command. Commands are grouped. Type 'help "COMMAND_GROUP"', (e.g. 'help "general"') for help on a command group. COMMAND GROUPS:   Group name: general   Commands: status, version, whoami   Group name: ddl   Commands: alter, alter_async, alter_status, create, describe, disable, disable_all, drop, drop_all, en  able, enable_all, exists, is_disabled, is_enabled, list, show_filters   Group name: dml   Commands: count, delete, deleteall, get, get_counter,

在這一篇文章中, 我們將介紹如何使用HTML透過PHP讀取hbase, 我們安裝的目錄結構為: hadoop                     /opt/hadoop hbase                        /opt/hbase 網頁根目錄             /var/www/ hbase的php目錄      /var/www/hbase thrift php                  /var/www/hbase/thrift php存放目錄           /var/www/php 測試程式之前，請先確定hbase , hadoop 都有正常運作中 $ bin/hbase thrift start 尚在執行 以下是我們的範例程式(example.php):     <!DOCTYPE html>     <html>     <meta charset="utf-8">     <head>     <script>     function getUser()     {     if(window.XMLHttpRequest)     {         xmlhttp = new XMLHttpRequest();         if(xmlhttp != null)         {             xmlhttp.onreadystatechange = stateChanged;             xmlhttp.open("Get","php/example.php",true);             xmlhttp.send();         }     }     else     {         alert('does not support XMLHttpRequest');     }     }     function stateChanged()     {     if(xmlhttp.readyState == 4)     {  

在 上一篇 文章中, 提及thrift server的建立與存取, 在這一篇文章中, 將介紹如何透過thrift存取hbase資料, 類似的內容,  waue0920 已經寫下詳細的紀錄, 因此, 我們將跟隨相同的架構, 並補充一些內容, 我們安裝的目錄結構為: hadoop                     /opt/hadoop hbase                        /opt/hbase 網頁根目錄             /var/www/ hbase的php目錄 /var/www/hbase thrift php                  /var/www/hbase/thrift 測試程式之前，請先確定hbase , hadoop 都有正常運作中 $ bin/hbase thrift start 尚在執行 以下是這次範例程式(example.php) <?php $GLOBALS['THRIFT_ROOT'] = '/var/www/hbase/thrift'; require_once( $GLOBALS['THRIFT_ROOT'].'/Thrift.php' ); require_once( $GLOBALS['THRIFT_ROOT'].'/transport/TSocket.php' ); require_once( $GLOBALS['THRIFT_ROOT'].'/transport/TBufferedTransport.php' ); require_once( $GLOBALS['THRIFT_ROOT'].'/protocol/TBinaryProtocol.php' ); require_once( $GLOBALS['THRIFT_ROOT'].'/packages/Hbase/Hbase.php' ); $socket = new TSocket('192.168.2.14',9090); $socket-&g