Castle on a Cloud

在很久以前的hbase java api介紹 (1)之後, 今天總算找時間寫了第二篇內容, 在此篇文章中, 將會敘述比較正規的java client寫作方式, 增進讀取hbase的效率, 以下是範例程式: import java.io.*; import java.net.*; import java.util.*; import java.lang.*; import org.apache.hadoop.hbase.*; import org.apache.hadoop.hbase.client.*; import org.apache.hadoop.hbase.util.*; import org.apache.hadoop.conf.Configuration; public class hbasetest2 {     public static Configuration conf;     static         {         conf = HBaseConfiguration.create();         conf.set("hbase.zookeeper.property.clientPort", "2222");         conf.set("hbase.zookeeper.quorum", "master,slave01,slave02");         conf.set("hbase.master", "master:600000");     }         static public void main(String[] args) throws Exception         {                 String[] TableFamily = {"col1", "col2", "col3"};                 createHBaseTable("testTable", TableFamily);          

在 LTE 網路中, Uplink 的定義是根據 E-UTRAN (Evolved Universal Terrestrial Access Network) 出發, 換句話說, 也就是 UE 到 eNB 的傳輸方向, 在 LTE 網路中, Uplink RSSI 主要代表兩種資訊: 第一種是作為 close-loop power control 的指標, 考慮到 LTE 網路會控制 UE 所使用的傳送功率, 一方面要為使用者節省傳輸功率, 另一方面要維持使用者的訊號品質, 因此, uplink RSSI 最好控制在一個固定的範圍內, 跟據上表, 我們可以發現, 透過 close-loop power control, UE 的 uplink RSSI 將被控制在 -105 ~ -100 (dBm) 的區間中, 因此, 若我們想用 path-loss 來模擬 uplink RSSI 和 UE 的訊號強度, 必須同時考慮 UE 的傳送訊號強度, 因此, 可以表示如下圖: 在圖上, 比較特別的部分是對於 PUSCH 和 PUCCH 有不同的計算方法, PUCCH 為 Physical Uplink Control CHannel, 每一個 UE 只擁有一個RB (Resource Block), 因此, 10log_10(RBs)=0, 不列於此算式內, PUSCH 為 Physical Uplink Shared CHannel, 每一個 UE 可以擁有多個 RB, 所以需求的傳送功率, 會隨著 RB 數量上升而上升, 在 LTE 網路下, 一個 eNB 服務多個 UE, 為了區別不同 UE 的 uplink RSSI, 對於 UE 訊號強度的量測會以 RSRP 取代, 若是要得到 RSRP 的資訊, 則必須得到 UE 傳送的 RB 位址, 所量測到的 RSRP 資訊, 將被包含在 LPPa 協定中的 E-CID Measurement Result 中. Measured Results 0 .. <maxnoMeas> >CHOICE Measured Results Value M

在雲端的架構中, 虛擬機 (virtual machine, or guest machine) 透過hypervisor取得實體機 (physical machine, or host machine) 的硬體資源, 其中, 有根據虛擬化的程度又分為許多不同的虛擬化技術, 像是virtualbox和VMWare的全虛擬化, 虛擬化完整的作業系統, docker或是LXC的container技術, 虛擬機像是一隻程式, 沒有獨立的作業系統, 另外, 還有一種辦虛擬化技術, host machine和guest machine共享Linux Kernel, 例如: KVM (Kernel-based Virtual Machine) http://www.linux-kvm.org/page/Main_Page 在本篇文章中, 我們將討論KVM架構下, host machine和guest machine之間的同步關係.

考慮到 LTE 網路中的定位需求, 除了 UE 必須負擔訊號量測的功能外, eNB 也在以網路為主的定位架構下, 負責訊號強度的量測, 相關的量測結果, 將透過 LPPa (LPP annex) 通訊協定將資訊傳至 core-network, 關於 LPP 和 LPPa 通訊協定, 我們將在之後介紹, 這篇文章將主要敘述 UE 和 eNB 的訊號強度量測. 對於 UE 而言, 訊號強度的量測主要是在 down-link channel, 並且對於 reference signal 以及其他 resource block 分別計算訊號強度, 並表示為 RSRQ 和 RSRP 的形式, 詳細的定義可以參考: http://note-on-clouds.blogspot.tw/2016/04/lte-rsrp-rssi-rsrq.html 對於 eNB 而言, 就會量測 up-link 的訊號強度, 並進行定位, 相對應的流程被稱作 Uplink E-CID Positioning Procedures, 定義於3GPP 36.305, 考慮到 up-link channel 並沒有相對應的 reference signal, 因此當 eNB 進行 up-link 訊號強度量測時, UE 必須在 up-link channel 發出相對應的 Sounding Reference Signal (SRS), 基於相同的機制, eNB 也將計算出相對應的 RSRP 數值, 作為 up-link 的訊號強度, 關於 SRS 的定義在 3GPP 36.211中. 注意到在 LTE 中 down-link 和 up-link 調變技術的不同, SRS 和 down-link reference signal 的分布也不一致. SRS 不只可以用作定位的相關資訊, 也可以作為 up-link scheduling 的相對應資訊. SRS 的資訊是在 LTE R8 中加入, 下表中列出了一些 physical signal 相對應的版本號: (資料來自於: An Introduction to LTE: LTE, LTE-Advanced, SAE and 4G Mobile Communications)