Castle on a Cloud

TPU就某種角度來說, 跨入了Intel的晶片事業, Intel面臨Nvidia和Google在deep learning上的夾擊, 挑戰其在運算單元的獨霸地位, 他們會如何回應呢? 首先, 他們併購了Altera, 取得FPGA (Field Programmable Gate Arrays) 的技術, 並且嘗試把FPGA和原本的計算架構 整合 , 提供一套整合的編譯介面, 根據在2016年4月的DEMO, FPGA加上CPU的能源效率可以改善70%, 且相關產品已經 出貨 , 然而, 我卻找不到其銷售資訊... 相較於TPU的ASIC架構, FPGA提供可動態編譯的硬體環境, 可以根據特殊指令集, 編譯FPGA硬體, 形成對應特殊功能的硬體計算模組, 提供比起ASIC的架構, FPGA的執行速度較慢, 但是能提供更為彈性的應用, 對於異質的deep learning架構而言, FPGA可能提供彈性而快速的服務框架, 另一種可行的作法, 則是直接分開對兩者進行編譯, 並透過QPI (Quick Path Interconnect) 介面互相溝通, 此類作法已有相對應的產品問世(E5-2600 v2, 目前最新版是v4), 然而就需要更多手動的設定, 說實話, 整合FPGA的版本號應該是E5-2600 v4, 時間為2016 Q2, 然而就算在2016Q4的產品中, 亦只看到對於QPI的支援, 而找不到整合的產品, http://ark.intel.com/zh-TW/products/96901/Intel-Xeon-Processor-E5-2699R-v4-55M-Cache-2_20-GHz 這一部分的資訊有些混亂, 且都未見於Intel官網說明詳細時程, 不太確定目前整合的進度, 以及產品推出的進度, 或許, 這原本就不是一個面向消費者的CPU產品吧...

然而, 真正讓deep learning衝擊人類信念的, 應該是Google Alpha Go和李世石的圍棋對弈, 2016年3月, Alpha Go以4比1擊敗世界棋王, 贏得圍棋的桂冠, 這背後的技術就是deep learning, 也是建立於這次介紹的TensorFlow, ( http://playground.tensorflow.org/ ) TensorFlow是一套開源平台, 由Google Brain團隊設計開發, https://www.tensorflow.org/ 在網路上有許多資源, 甚至有中文的社群: http://www.tensorfly.cn/ 相較於CUDA, TensorFlowr提供了一套資源調配技術, 可以分配運算資源到CPU或是 (藉由CUDA driver存取的) GPU中運算, 相對於傳統的deep learning運算方式, TensorFlow可以定義節點上更複雜的運算. 此時, 整個運算的框架, 更近似於傳統的HPC計算模式, 或者稱之為: Data Flow Graph

deep learning大概是繼雲端以來, 下一個在台灣炒熱的學術名詞, 很多人把這兩個名詞相提並論, 認為這都是用以解析大數據的工具, 然而, 在系統的架構與設計上來說, 雲端預算和deep learning是完全不同, 甚至相反的概念, ( https://research.googleblog.com/2015/06/inceptionism-going-deeper-into-neural.html ) 以平行化的角度來說, 雲端運算, 或者說, Map-Reduce的平行化技術的重點在於: 搬移程式不搬移資料, 這裡的假設是資料量極大(大於1TB), 為了處理巨量資料, Map-Reduce的架構重點在於資料的容錯性, 雲端平台的擴展性, 以及彈性的資源規劃, 至於deep learning, 在運算架構上則更接近於HPC (high-performance computing) 利用實體機內的多核(CPU or GPU), 提供大量且即時的運算, 用以提供許多簡單, 重複, 且平行的運算環境.

假如所有知識都可以在網路上取得, 可以藉由多媒體, 甚至 VR 給你身歷其境的感覺, 那麼, 博物館, 或是圖書館存在的意義是甚麼呢? (紐約地下鐵的馬賽克磁磚) 對於我而言, 是一種知識的組織, 給予我們一套體系, 關於專家如何組織那個領域的知識, 畢竟, 知識並不是單獨存在的, 很多時候, 你甚至必須回到其歷史脈絡中, 才能找到他的意義... 這次美國行, 一共走了5處博物館與公共圖書館, 分別是: 國會圖書館, 紐約公共圖書館, 紐約自然歷史博物館,  大都會博物館以及當代藝術博物館 (MoMA), 為了避免流水帳, 文章將以主題方式呈現, 分別為: 公共空間與功能空間, 瑣碎的藝術, 策展人的條件. (紐約公共圖書館外觀, 同時也是一個古蹟建築) (A) 公共空間與功能空間 建築空間一定是為了特定目的下所設想的, 然而, 圖書館或是博物館卻像是有機體一般, 會隨著時間改變, 於是, 困難就出現了, 要如何在這些老舊的軀幹中, 放入新興的靈魂呢? 對於美國而言, 或許是因為她是一個 200 年的年輕國家, 有著很開放的看法, 所以, 你可以在博物館與圖書館內辦桌, 把原本的側翼空地改成影音館, 把大廳淨空放上聖誕樹, 準備好特展廳, 而把真正的功能 (像是圖書查詢) 移到新建的館舍, 這樣的想法, 對於出生於台灣的自己來說, 有些難以接受, 總覺得圖書館和博物館該是肅靜與神聖的場合, 然而, 或許也只有在走下聖壇後, 才可以和民眾有更近距離的接觸. (大都會博物館中的美國館, 藉由情境重現, 表現當代工藝) (B) 瑣碎的藝術 對於一家重量級的博物館而言, 通常的煩惱不是展品太少而是太多, 要如何取捨? 如何組織展品形成故事, 是策展人的一大考驗, 對於紐約大都會博物館而言, 美國館就是一個很困難表現的目標, 不像是自然歷史博物館可以直接借鏡分類學與演化史, 也不像是畫作收藏, 可以用流派與藝術家社群連結來策展, 這裡有很大一部分的收藏是家具, 或者說, 當代工藝品, 風格相似, 數量龐大, 而難有強烈的創作者色彩, 因此, 大都會博物館決定以編年方式呈現, 並為了每個年代準備一個典型的房間風格, 讓觀眾可以想像, 在這樣...

在紐約, broadway 代表兩件事, 一方面是一條穿越曼哈頓市區的道路, 另外一方面, 就是音樂劇. (夜晚的TKTS, 就在時代廣場觀景台下) 在台灣的我們, 由於當年韋伯所帶來的"貓"和"歌劇魅影"熱潮, 讓我們對於音樂劇這個詞並不陌生, 根據 wiki 上的簡短定義: "音樂劇（英語：Musical theater，簡稱Musicals），早期譯稱為歌舞劇，是音樂、歌曲、舞蹈、戲劇、雜耍、特技和綜藝結合的一種音樂表演。" 音樂劇是一種跨界結合的產物, 同時結合多種藝術表演風貌, 也因此, 不同音樂劇提供了全然不同的風貌. 在紐約行中, 我最想看的其實是 "RENT (吉屋出租)", 不過, 不幸的是, 並沒有上演, 取而代之的是, 我看了"歌劇魅影", "屋頂上的提琴手", "芝加哥", "In Transit", 這四部, 風格, 結合元素都不相同的音樂劇. (歌劇魅影的舞台, 白色布幕下就是那一盞吊燈) (A) The phantom of the Opera http://www.broadway.com/shows/the-phantom-of-the-opera/ 在紐約, 看的第一部音樂劇是歌劇魅影, 劇情, 音樂, 甚至是吊燈掉落的橋段, 都由於這齣音樂劇的大名遠播, 而事前熟知. 以音樂劇而言, 歌劇魅影結合的就是芭蕾舞和歌劇, 舞台上的演員, 至少在我這個外行人眼中, 都有傑出的芭蕾舞演出基礎, 在演員編制上, 每個角色也清楚地扮演著, 丑角 (劇院經理, 男女高音), 主角群 (魅影, 克莉絲汀, 勞爾), 以及用以串接劇情的配角 (梅格, 吉瑞夫人) 個人也有自己的主題音樂, 算是傳統熟知的音樂劇演出. 拜科技所賜, 魅影的 "I am here" 的呼聲真的是環劇院出現, 相較於全本的小說, 音樂劇的劇情取捨上相當有巧思, 如果作為音樂劇新手, 只看一齣音樂劇的話, 十分推薦歌劇魅影作為入門之作. (Fiddler的舞台, 一個俄羅斯的小鎮, 可以跟前面的工作人員買...

接下來, 讓我們談談紐約的 3C 產品吧! 這一篇, 與其說是遊記, 不如說是感想, 所以圖片極少, 請讀者見諒. (bestbuy 的傳單, 筆電品牌被 hp 和 Dell 主導) 在紐約, 主要的筆記型電腦品牌包括蘋果, Dell和hp. 智慧型手機最大宗是蘋果, 其他則有三星和LG. 如你所見, 台灣的品牌在這裡缺乏一席之地. 為了尋找原因, 我們走進了 bestbuy, 在這個全美連鎖的販賣店中, 聯想, Dell 和 hp 都有自己的展示櫃. Asus 和 Acer 在同一區, 售價和台灣差別不大. 至於手機, 我只看到 LG 和三星, 三星的廣告大到時代廣場有專屬廣告牆, 同時還有其他廣告牆24小時放送著. 可以想像的, 身為美國人, 當然不會買這些台灣品牌, 並不是他們不夠好, 而就像是你在台灣不會買 Dell 一樣, 一方面, 不那麼熟悉, 另一方面, 保固和維修的便利性, 也是考量重點. 然而, 這就像是惡性循環, 當售出的數量減少時, 平均建立維修據點的價格就上升, 這些固定成本造成利潤下滑甚至虧損, 迎來的是更困難的經營環境. 對此, Acer 和 Asus 採取不同的策略, Asus 採取和通路合作的模式, 想辦法在第一時間給予新平台的解決方案, 藉此換取在通路的曝光機會. 而 Acer 則把目光轉向 Chromebook, 在 Google 豐厚的補貼下, 取得曝光所需要的資源以及利潤. Htc 在另一方面, 幫 Google 代工 pixel 也是相同的模式. 也是借用 Google 豐厚的資源推廣自家生產的產品, 取得利潤, 不過代價是讓自己再度成為代工商... (順帶一提, 我在紐約唯一看到 Htc 廣告的地方是大都會博物館的無線網路登入廣告, 這或許說明另一件事, 也就是在支援極有限下, 只有利用新媒介, 對特定用戶投放廣告, 才是這些小資本品牌商的生存之道.) (三星在 bestbuy 的店內店, 圖片來自網路) 綜合來說, 台灣品牌的困境來自於行銷資源的缺乏, 這一部分跟先天體質相關, 在上述三家品牌商中, 只有 Asus 是多角經營的品牌, 然而其規模, 比起包山包海的三星, LG 和 Sony, 仍遠遠不及...

因為參加 GlobeCom 2016 的緣故, 初次踏上美國的土地, 當飛機降落時, 夜晚的紐約一片燈火通明, 真有一種海上鋼琴師中, 看到自由女神像, 想要大喊: AMERICA 的衝動. (遠眺自由女神像) 很快的, 9天一晃而過, 去了四趟博物館, 看了四場百老匯, 搭了20多趟地鐵, 走了超過15萬步, 想說記錄下甚麼吧? 遊記多如過江之鯽, 不缺此一篇, 何況個人不喜歡拍照. 於是, 就簡短記錄下一些觀察和感想, 並按主題分成三部分: (2) 3C in NYC: 台灣品牌在紐約? (3) Musical: 音樂劇, 跨界, 與寒風中的 TKTS (4) Museum: 知識的組織 剩下的生活雜感, 就在這一篇中紀錄吧! (A) 地鐵 (紐約地鐵, 有如哈利波特的地精坑道) 在紐約, 最重要的卡片, 應該是地鐵票... 在 In Transit 中, 有一個橋段就是說 metro card 是某人破產後的最後一張卡(笑 紐約地鐵與其說是捷運, 不如說是電聯車, 由駕駛控制, 缺乏良好的中控系統, 每天都在莫名的延遲, 垃圾散落在鐵軌, 月台髒亂, 甚至有飲料倒在車廂內, 但是, 這是全世界最大的通勤系統, 也是紐約客賴以為生的交通工具, 我每天平均要在地鐵中待上兩小時... 紐約地鐵以磁卡作為票券, 計次為2.75美元 (85元), 有七日票, 作為觀光客, 請一定要買, 否則旅費將成為一大支出, 地鐵中的網路極差, 號稱有免費WiFi, 但是多數時間連不上, 每日的地鐵報會是你的好幫手 (我因此坐過站兩次...) 在地鐵上, 旅客通常活動包括: 看書, 滑手機遊戲, 聽音樂, 聊天, 我想網路不便的好處, 就是維持部份的讀書風氣, 紐約地鐵也是目前看到最多次kindle的地方, 因為真的需要吧(笑 (B) 食物 (brgr的素漢堡, 裡面加入了酪梨, 非常健康!) 在紐約, 按台灣物價, 兩倍算是便宜, 三倍算是合理, 一倍或是更低的物品, 就我所知, 包括: 日清泡麵, 蛋, 牛奶, 果汁, 因此, 這些東西就是我的早餐和晚餐, 作為生長在華人圈的人們, 請不要輕易嘗試這裡的中式食物, 我嘗試過三次, 包括一曾是米其林一星的餐廳, 每一次都很失...

為了在室內與小細胞基地台的環境下提供定位資訊，3GPP組織於2014年成立了Study Group (Study on Indoor Positioning Enhancements for UTRA and LTE) 探討小細胞基地台在室內環境中的定位問題，比起之前36.809的Study Group，此次室內定位的標準制訂有更多廠商加入，且標準制定的討論更為密集，最後2015年9月完成了相對應的技術報告 (3GPP TR 37.857)，同時，也建立Work Item (FS_UTRA_LTE_iPos_enh) 開始進行標準化，目前在3GPP網站上顯示其標準化的進度為13%，目前尚未對於既有的LTE協定進行提案與修正。 根據3GPP所提供的技術報告 (3GPP TR 37.857)，探討了CID和OTDOA兩種定位方法在不同的應用情境下的定位誤差，其中，包含了大基地台 (Macro Cell) 和小基地台 (Smell Cell) 共存的室內外應用環境，同時，也包含了一種純粹室內的應用環境。考慮到我們的研究情境，我們將特別討論在室內的應用環境中LTE系統的定位應用。在TR 37.857的室內應用環境中，假設使用者均勻分布在許多四層樓建築中，每層樓皆為50公尺乘120公尺的格局，且內含4個小細胞基地台，這些建築將隨機的分佈在大基地台 (Macro Cell) 的服務區 (Cell) 中。在此應用環境中，所有的使用者終端都存在於室內的環境，模擬的定位水平中位誤差對於OTDOA而言，約為6至15公尺，對於CID而言，約為15公尺，詳細的模擬結果顯示於下圖[TR 37.857]。 左圖為使用CID的水平定位誤差，右圖為使用OTDOA的水平定位誤差

定位基準信號（PRS）是新加入到LTE Release 9的功能之一，用來確認用radio access network通訊時信息的User Equipment (UE)的位置。PRS的重要性是使用PRS的UE可以支持須要使用所在位置的服務，像是導航，緊急呼叫等。PRS是一種控制訊號，根據設定，占用某些OFDM symbol，UE可以藉由對PRS訊號的接收與量測，估測UE到eNB之間的時間，轉換成OTDOA的資訊，對於UE的位置進行估測。 PRS主要分成三個步驟： UE 接收來自 cells的 PRS 包括Reference cell以及Neighbor cells，其中，Reference cell為服務基地台，而Neighbor cells為相鄰的基地台 以接收到的PRS為依據，UE量測Observed Time Difference of Arrival (OTDOA)，並回傳RSTD給服務的基地台 從UE接收到 reported reference signal time difference (RSTD)，然後eNodeB 透過LPP或是USRP將資訊送到遠方的位置伺服器進行計算

到達時間差量測法 (OTDOA) 是一種定位方法的選擇。它利用觀察鄰近基地台的訊號(Positioning Reference Signal，PRS) 取得相對於服務基地台的到達時間差。根據此時間差以及基地台的地理位置，我們可以得到一組以兩個基地台為中心的雙曲線，根據至少三對的基地台的量測組合，我們可以根據最小平方法 (Least Square) 估計出使用者裝置的位置。

全球定位系統 (Global Positioning System)，又稱全球衛星導航系統(Global Navigation Satellite System)，簡稱 GPS或是GNSS。 是一個中距離圓型軌道衛星導航系統，可以為地球表面絕大部分地區 (98%) 提供準確的定位、測速和高精度的時間標準。至少需要其中 3 顆衛星，就能迅速確定用戶端在地球上所處的位置及海拔高度，所接收到的衛星訊號數越多，解碼出來的位置就越精確。可滿足位於全球任何地方或近地空間的軍事用戶連續精確的確定三維位置、三維運動和時間的需要。

CID (Cell ID)是根據服務基地台的地理座標，作為定位的資訊。 服務基地台的資訊可以透過位置更新 (TA updating，TAU) 的訊息或呼叫 (paging) 等方式獲得，這位置精度便會與基地台覆蓋範圍的大小有關。 在過往的行動網路中，只利用了行動裝置連上哪個服務基地台的資訊，這個方法在大基地台 (macro cell) 的架構下誤差很大，甚至無法滿足FCC所要求的精度 (50公尺)，為了增進定位精確度LTE被提出時就定義了E-CID (Enhanced Cell ID)的定位方法，除了使用服務基地台的地理座標的資訊，同時利用量測的資訊，主要是：參考訊號功率 (Reference Signal Received Power，RSRP)，或者到達時間差 (TDOA) 和時間前置 (Timing Advance，TADV) 的量測，或者來回時間 (Round Trip Time，RTT) 來估測使用者終端與基地台之間的距離，甚至可以利用到達角度 (Angle-of-Arrival，AoA) 的資訊來進行定位。

對於3GPP LTE網路以及其他既有的行動網路，有兩種不同的定位框架，第一種是藉由資料平面 (User Plane，U-Plane) 進行，例如： SUPL (Secure User Plane Location) 或是 LPP (LTE Positioning Protocol)。 其中，SUPL是一般用途的定位協議，由開放行動聯盟 (Open Mobile Alliance，OMA) 所制定，提供不同通訊系統一種共通的定位介面。 可以參考:  https://en.wikipedia.org/wiki/Secure_User_Plane_Location 第二種則是藉由控制網路 (Control Plane，C-Plane) 進行，這一部分，對於不同的通訊網路，就採用不同的通訊協定，以LTE為例，仍舊是使用LPP通訊協定。 可以參考:  https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2441 Ericson, “positioning with LTE”, September 2011

在LTE的定位服務中，依據定位的發起者，可以分成三種類型：UE-based、UE-assisted以及eNB-assisted。 其中，eNB-assisted和UE-assisted分別表示定位時的量測的主體，可能是行動裝置 (UE) 或者是基地台 (eNB)，UE-based則代表UE是位置估測的主體。 按照此類分類方法，GNSS定位為UE自行量測衛星訊號並計算定位結果，屬於UE-based定位方法，E-CID和OTDOA (包含UTDOA) 都是在E-SMLC中計算，將依據量測主體的不同而分成eNB-assisted和UE-assisted兩種方法。詳細的分類可以被歸類成以下表格。 Rohde & Schwarz , “LTE Location Based Services Technology Introduction”, April 2013

在上一篇文章中, 我們記錄下一篇問題: https://bugs.launchpad.net/ceilometer/+bug/1457923 其中, 發問的主題, 也就是heat stack的取樣時間必須和ceilometer的時間一致, 為了解釋原因, 我們必須先了解heat和ceilometer的偕同架構, 以最簡單的圖說來說, 可以以下圖來表示: http://www.slideshare.net/NicolasBarcet/ceilometer-heatequalsalarming-icehousesummit

在OpenStack中, 當我們要利用hest開啟一個機櫃, 並根據一些數值進行auto-scaling時, 我們常常遇到一些問題, 例如: 到底現在ceilometer讀到的數值為何? 是否到達scaling out/ scaling down的標準? 這些問題都可以利用heat和ceilometer的command line interface (CLI)來查詢, http://docs.openstack.org/cli-reference/heat.html http://docs.openstack.org/cli-reference/ceilometer.html 在以下內容中, 我們將介紹一些常用的CLI, 並說明這些CLI的功能,

在上述的測試中, 都是在controller node上創造heat stack, 然而, 這樣的架構需要存取controller node, 並不符合public cloud的自動化處理與安全性架構, 若是我們想要從遠方創造一個heat stack, 或是更新heat stack, 我們該怎麼做呢? [root@blade02 ~(cr)]# heat stack-create second_stack -f first.yaml -P "key=test" +----------------------------+--------------+--------------------+----------------------+ | id                         | stack_name   | stack_status       | creation_time        | +----------------------------+--------------+--------------------+----------------------+ |****-44ae-93b7-de8e61e79007 | second_stack | CREATE_IN_PROGRESS | 2016-07-19T04:35:10Z | +----------------------------+--------------+--------------------+----------------------+

在上一篇文章中 ( 這裡 ), 我們跟隨官網上的範例, 寫了一個簡單的template, 然而, 我們回顧一下在nova上開啟虛擬機的程序, 包括: 指定虛擬機映象檔, 選擇虛擬機樣板 (flavor), 選擇登入金鑰 (key), 同時, 還要選擇虛擬機網路與防火牆規則, 在上一篇template中, 並不包括網路與防火牆部分, 因此, 若是直接採用上一篇的template, 會得到以下的結果: | stack_status         | CREATE_FAILED                                                    | | stack_status_reason  | Resource CREATE failed: BadRequest: Multiple possible            | |                      | networks found, use a Network ID to be more specific.            | |                      | (HTTP 400) (Request-ID: req-                                     | | ...

在OpenStack的架構中, Scaling是由heat project完成的, 在heat project中, 每一個由虛擬機組成的群組稱為stack, 而stack中的創建甚至動態擴充機制, 則有賴於HOT (Heat Orchestration Template) template的設定, 我們先來看一個最簡單的template範例: heat_template_version: 2015-04-30 description: Simple template to deploy a single compute instance resources:   my_instance:     type: OS::Nova::Server     properties:       key_name: my_key       image: ubuntu-trusty-x86_64       flavor: m1.small

在Spark的介紹中, 我們可以看到Spark的相關的專案: Spark runs on Java 7+, Python 2.6+ and R 3.1+. For the Scala API, Spark 1.6.1 uses Scala 2.10. You will need to use a compatible Scala version (2.10.x). 其中, 需要預先安裝的元件包括: Java (1.7版本以上) Scala (2.10版本以上) 在這一篇文章中, 將在ubuntu 16.02上安裝spark的測試環境,

在很久以前的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[] Tab...

在 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) ...

在一般通訊系統中, 我們常用 RSSI (Received Signal Strength Indication) 來表示訊號強度,  其單位為 (dBm), 可以轉換成功率大小 (mW): https://en.wikipedia.org/wiki/DBm [註] dBm 的原意即是: (dB) reference to (m)W, 因此, 1 W = 10*log10(1000mW) = 30dBm. 在 LTE 通訊系統中, 除了 RSSI 之外, 又額外定義了兩個用以標示訊號強度的數值: RSRP 和 RSRQ 以下, 我們將介紹 RSRP, RSRQ 和 RSSI 的不同： Reference Symbol Received Power (RSRP) RSRP 為 UE 量測 Reference Signals (RS) 的平均訊號強度, DRS 為基地台在下行訊號中, 於固定 RB (Resource Block) 上傳送的訊號, 由於這些訊號具有特定的傳送格式, 接收端便可以解出這些控制訊號的強度, 對於不同的相鄰基地台, 甚至是同一基地台不同的天線, 可以透過不同的 RS 配置, 讓使用者得知不同目標的量測數值, 如下圖所示: 紅色為 RS, 不同基地台或天線使用不同的 RS 排列方法, 可分開量測 來自: https://api.semanticscholar.org/CorpusID:22030582 RSRP 的回報由 UE 進行 Measurement Report, 回傳給基地台, 其中, 關於 Measurement Report 的設置定義於 RRC 的規範中, 我們之後有機會再提, RSRP 的量測, 通常在換手 (handover) 時進行量測, 用以指出目標基地台的訊號強度, 其中, UE 所量測的數值, 將藉由下表進行轉換 (訊號強度 (dBm) - (-140)), 並回報給 eNB 作為換手的決策使用: (3GPP Reference: TS 36.133) RSSI (Received Signal Strength Indication)  RSSI 是 UE 接收到的 wide-band 訊號強度, 包含 DRS 以及其他...