Category: Mobile

Posted on
by

這篇文章是 2008 年第三季思考所謂 Shared Infrastructure 的可行性，所整理，草稿寫好至今，一直沒有刊出。現在稍加編修後釋出。文中部份資訊可能已經失真，一些試算表與見解並未完整揭露，敬請見諒。

2008 年中，曾經研究過 CWIRP 的 Amelia Bryne Potter 與 Ryerson University 的 Catherine Middleton 於 2008 年六月在 國際電信協會雙年會所發表的一篇論文，Is it Good to Share? A Case Study of FON and Meraki Approaches to Broadband Provision。

這論文主要是分析 2008 年時市場上兩個主要的經營「user-generated」無線網路基礎建設 (Shared Infrastructure) 的公司，FON 與 Meraki 的經營策略與模式，並判斷這兩家公司的策略是否可以確實經營一個良好的公眾網際網路服務。

CWIRP 的背景是 Infrastructure Canada 所贊助的研究計畫，主要研究方向是

  • 共享型無線網路基礎建設 (Shared/Publicly-owned Infrastructure) 或 管制型無線網路基礎建設 (controlled Infrastructure) 的相關理論
  • 加拿大現有的公眾 ICT 基礎建設計畫研究
  • 關於基礎建設的佈建 (deployment)、技術選擇 (technology choice)、 創新 (innovation)、投資 (investment)、管理 (governance), 採用 (adoption) 與使用 (use) 的不同模式與最佳作法。
  • 共享型無線網路基礎建設的公眾利益等
  • 對於共享型無線網路基礎建設的宣傳與維持應實施何種政策與支持

基於上述的課題，CWIRP 過去已經發表三十多篇論文，主要的形式都是深入的案例探討。

而這篇 ‘Is it Good to Share?‘ 則是深入的討論了 FON 與 Meraki 兩家公司的佈建策略與實際網路服務的狀況。 此論文中的論述幾乎全數引用網路上的片段對話，並未實際進行測試與觀測，論文結論值得參考，但稍嫌主觀。

可取的是論文中以下述幾項標的作為評斷標準

  • 可用性 (Usable)
  • 有益性 (Useful)
  • 可靠性 (Reliable)
  • 高品質 (High quality)
  • 持續性 (Sustainable)
  • 佈建普及性 (Ubiquitous)
  • 安全性 (Secure)
  • 費用普及性 (Affordable)

這篇 ‘Is it Good to Share?‘ 簡報與論文的結論是，雖然這兩家公司所使用的策略可以在中短期間內建立起網路，但是無法提供一個穩健 (robust)、可靠 (reliable)、與高品質 (high quality) 的基礎建設。同時 Meraki 相對於 FON 似乎較為成功，主要是可用性相較之下較高。而 FON 由於持續其商務模式的前景不甚明朗 (沒有人可以於目前評斷)，很可能造成網路的未來維運出現變數。

這篇論文點出一個現實，無線網路基礎建設最重要的就是可靠性與有益性。

另外一個問題是，即便採取相對較容易擴增搭建的 Mesh Network 技術，還是要先克服基本的密集度。以 FON 與 Meraki 所使用的 WiFi 技術，礙於 802.11b/g 的規格限制與 ISM 無線電頻譜的功率問題，在都市內受限於建築物的屏蔽，即便從馬路一邊傳到馬路對岸，很大可能無法取得直線視角 (Line of sight)，受到建築物的干擾而產生繞射或多重路徑的干擾，以及功率的限制，也讓無線訊號無法傳到較遠的目標地。

除了安裝位置外，即便社區內有相當多居民達成共識，願意將基地台搭設於屋頂或其他收訊良好的場所，藉由專業的無線電訊號測量、評估與安裝設定，來提高可用性。但依然還有其他的問題，包含了調解頻譜分派 (Spectrum assignments)、網際網路路由器數量與 Mesh Network 的最佳配置等等，這些問題影響了傳輸節點隨時可能失效的問題，也很容易造成網路的可靠性大量下降。

我實在認為，由於一般的無線網路機制的技術瓶頸，再純粹依賴住家或一般網際網路者，著實難以建立這樣的網路。WiFi 用於家用網路是一回事，城市級規模，則需要些專業規劃，或更強的 RF 自動化調適機制。依照目前大城市如北市、香港、東京的頻譜擁擠程度，你實在無法預設將機器開啟它就會自動運作的情境。

這種技術上的瓶頸可以從實例中看出，例如 WIFLY 與 FON 在台北市的網路系統。

根據 2007 年 10 月林奕華議員在市議會的質詢中，他引用了自己的使用經驗，與 PC Zone 的論壇討論，指稱「WIFLY 品質使用極差」，甚至會因為網路品質太差，而脾氣暴躁犯了憂鬱症。

另外，根據 TWNIC 在 2007, 2008 年的研究報告，在 2007 年的台灣無線網路使用調查報告，大約 1/4 的使用者使用過無線上網 (此為廣義無線上網使用者，即包含 WiFi 與 3G)，使用者最關心的則是「擁有無線上網設備」、「上網設備輕便」、「上網設備普及化」及「戶外及室內皆可無線上網」。

2008 年的調查，一般民眾的使用則向上成長成 36.33%。「搜尋資訊」、「瀏覽資訊與網頁」和「收發電子郵件」是最常使用的功能。線路不穩、連線品質不佳是目前無線網路使用者最常遇到的困擾，有趣的是，這份調查中一般民眾對於無線網路品質的滿意度高達六成，而網路受訪者的滿意度只有 26%。使用者會使用無線網路的地點是「咖啡廳、餐廳、速食店」、「捷運站、機場、火車站」及「家中」。

從近幾年來歐美大量 Municipal Wireless Network 失敗案例，如 EarthLink, MetroFi, Kite Networks 很明顯的看到沒有健全的營收現金流，單靠廣告，或者少量的使用者，實在難以支持膨大的網路建設成本。如加上台北 WIFLY 的案例，安源投資了十一億，但卻換了差異極大的營收比例(更別說更早一點北中南各地陸續成立但皆以失敗結尾的鄉鎮區域性無線網路服務商)，根據 2009 年 10 月 5 日，陳玉梅的質詢，WIFLY 的使用量已經低到變成網路鬼城的程度，營收顯然不會太好看，我相信無法滿足基本的營運成本。

若要營運一個 Municipal WiFi，降低資本支出(CAPEX)，財務才能早日支持營運成本 (OPEX)，從這個角度來看，Shared Infrastructure 是最有機會的。

再從台灣市場的潛在使用者來分析，2010 年全台的 WiFi 網路使用者大約有 460 萬人 (3G 則有 215 萬人)，台北市則約有 75 萬到百萬之間，若操作得當，應該還是有機會支持一個 Shared Infrastructure 的 Municipal WiFi 網路系統的營運 (但大概不會賺好幾倍就是)，要賺錢還是得有其他營收項目。

根據上述的幾點市場數據，針對 Shared Infrastructure WiFi ，我猜想會有幾個作法 (除了台灣之外，其他大都市的策略可能略同)  –

  1. 透過電信商補貼進入家用用戶。僅提高普及度，商業模式可能為硬體與基礎建設服務費用
  2. 針對咖啡店、餐廳、速度店，提供電路免費，收費之無線網路服務。商業模式為拆帳或硬體銷售費用，後端支援之服務必須完備，如試用卡、客服機制務必完備等。
  3. 一新網路管理後台，提供即時的智慧型 RF 管理、維運機制。透過一般銷售通路或代理商進入市場。商業模式為拆帳或硬體銷售費用。

備註: FON 近年已經營業範圍，將重心專注於有無線網路付費習慣的歐洲區域，主要通路為電信營運商，利用搭售與拆帳方式取得網路擴展速度與增加營收，主要使用者為家中有無線網路需求者，漫遊上網顯非主要需求，新有產品已經終止初期的大幅補貼模式，再經過大幅的削減營運規模與成本後，已達到營收平衡。至於 Meraki 也更改售價策略，專注於提供商業化 Mesh Network 解決方案，甚至做了一些措施，將客戶綁死在他們的收費平台上。因此有衍生的其他商業機制替代如 Open-Mesh 等。

Posted on
by

先前裝了 HelloTxt 的 Ubiquity Script 來用，以便於可以在 Firefox 中直接用 Ubiquity 介面來更新自己的狀態到多個微網誌。不過 Hellotxt 的 script 是針對早期 Ubiquity 版本所撰寫，因此在 0.5 版釋出後，原 Script 不相容於新 Parser 2 API，因此幾個月前就無法使用了，官方也一直未修正。於是自立自強的依照 Parser 2 API Conversion Tutorial 修正一版，可於此網址安裝或下載 patch。

自己已經用了 Ubiquity 一陣子，目前使用經驗良好，值得推薦給你使用。但網路上介紹已相當多，除了 Mr6 的「開啟比 Google寬一千倍的路」目光短視的膚淺廢話不要浪費時間之外，其他的使用面介紹都可參考。這裡就不多費唇舌，你想了解基本的使用方法可以參考 Ubiquity 0.1 實際操作過程的精彩影片示範一文。

若可聽讀英文或日文，可讀 mitcho 在 Tokyo 2.0 的精彩演講 Ubiquity: Command the Web with Language 言葉で操作するWeb (簡報)，mitcho (Michael  Yoshitaka  Erlewine) 現在是 MIT Department of Linguistics 博士生，之前在 Mozilla Lab 擔任研究員開發 Ubiquity。

Ubiquity 的指令與功能極多，逐一介紹極耗時，請安裝後利用 list ubiquity commands 指令取得各項功能說明。

自從新版的 Ubiquity 的 Mozilla Web Search Commands 整合了 Firefox 的 Open Search 功能後，我就可以直接用 search 指令查詢自建的 Open Search Plugins。過去雖然依照自己的需求建立了十幾個不同的 open search plugin 來找不同的郵遞論壇、BTS、搜尋引擎、拍賣等，但是用滑鼠切換搜尋引擎絲毫沒有可用性可言。

新版的 Ubiquity 可讓你利用鍵盤快速搜尋所選文字，而且常用的指令會排序再前頭，也可以直接選擇文字後透過滑鼠右鍵執行該指令。因此除了內建的 IMDB, Wikipedia 外，我自己最常用得就是 amazon, aNobii, FindBook, 博客來、臺北市立圖書館館藏間互查書籍，一邊在 aNobii 規劃書單，一方面在不同的地方查詢藏書。

過去查詢一本書，你得「複製」、「開啟新頁」、「連上特定網站」、「貼上」、「搜尋」等幾個步驟，現在一樣是選取可以直接用右鍵選擇該服務，或者叫出 Ubiquity 的搜尋介面鍵入該服務名稱即可，也避免在複製貼上間還得找網頁的輸入欄位。剪貼行為總是很快讓我進入昏睡狀態。

另外一個值得提的指令是 Marcello Herreshoff 的 create search command，之前建立自己的 Open Search plugins 程序其實有點複雜，即便利用 Ready2Search 或 Search Plugins Generator 等工具也需要一些步驟。這個指令只要選定一個搜尋欄位，鍵入 create search command 名稱 就會自動產生一組 Ubiquity 專用指令，一行程式都不需要寫！非常好用。另外你也可以利用 create bookmarklet command 把你常用的 bookmarklet 轉成 Ubiquity 指令。

即便我自己最常使用的還是搜尋引擎等指令，但是我相當看好 Ubiquity 的未來發展。不少人認為 Ubiquity 僅多提供 Web 的 CLI 的介面，也有些人質疑指令列根本就是走退路，未能體會 Ubiquity 的多國自然語言介面設計理念。

事實上，對電腦下命令不難，難的是背指令後依照指定語法下命令。

CLI 介面最令人畏懼的是得背下指令名稱，還得依據其指定之語法給予參數。而多國自然語言介面的設計用意就是，讓使用者盡量用熟悉的口語方式給予指令，不讓使用者強記。替代日漸繁雜的選單與功能列，取而代之是選取文字後使用「search this with Findbook」、「到 Findbook 查這個」的這種指令方法。

在新版 Ubiquity 的 Parser 2 中，Ubiquity 帶入了 semantic roles 的指令設計，搭配先前設計的名詞詞性 (Nountypes)，可以更精確的分析使用者欲執行的指令。再研究過眾多語言的文法架構後，在語意分析器設計上也可有彈性的適應於不同語系，現在你可以依照自己的語言特性設定 Branching、斷詞等方式，讓分析器再判斷完介係詞、分隔字後正確判斷文句意義。因此未來除了現有的英文語系之外，你也可以使用中文來下達指令，再接下來的計畫中，也會納入 Command chaining，於是或許接下來你就可以直接對電腦說「到 Findbook 查這個並寄給 Rex」這種語法。

不少人拿 Ubiquity 跟一般桌面的 Launcher applications 作比較，像是 MacOS 上的 Quicksilver 介面，或 Linux 上的 Gnome-Do 等。但是桌面系統的特性畢竟跟網頁略有不同，許多桌面工具並非文字導向，應用上並沒有像網頁間互相傳輸字串那樣自然。

我最期待的幻想其實是希望這套系統可以置入行動裝置，並結合語音辨識功能。雖說現在許多智慧型手機已內建語音辨識，但常常都還只是啟動電腦或直接撥打電話這樣程度的應用，軟體若可以知道自己接受哪些參數，或許就可以利用觸控螢幕輸入欲傳送之「物件」(object) 並用語音給予指令了。這樣的應用相對只需要聽懂指令，可以避免以語音給予「物件」數值時容易聽錯的缺點。

Posted on
by

應 OpenLab Taipei 的朋友之約，在共玩二號分享了一份非常久之前的活動，在 2006 年底到 2007 年初的 PORTA2030 工作坊經驗。試著借用 rainfrog 的評論文字，知道無論如何大約二、三十分鐘的時間，大約無法涵蓋所有的可能角度。因此，此次只能從軟體開發者的角度進行探討，想了解此次工作坊中軟體開發與設計的經驗，以及所謂「跨領域」的合作經驗。

本來跨領域這塊的探討，想丟給當初負責主要溝通的 macpaul 來談，沒想到他居然再趕來演講的路上出了車禍。因此我只好就我所知的部份進行分享。演講錄影應該很快可以在 Youtube 上看到。 演講一開始我便澄清自己並不是數位藝術家，認真要談數位藝術或裝置藝術的經驗，大概就是之前作過手機與自動販賣機的整合。本段分享是從軟體開發者的角度出發，分析這場所謂的數位藝術或行動藝術的參與。

我必須承認，現在看來，這是一個幼稚且不成熟的展出。從一無所知展覽的形式與支持方式開始，到中途才驚覺其實自己是被展示的物件。用心搭建了一座只有軟體開發者看得懂的巴別塔 (費心翻譯打造的 trac 專案管理系統)，註定了軟體開發與服裝設計兩組人馬的溝通隔閡，缺乏跨界溝通的經驗與技巧，兩方持續成平行線前進直到結束。若當初能有更成熟的引導溝通方式，或許最後會呈現出不同的作品。不過這整件事還是為自己累積了相當的經驗，無論是技術上或是心智上的進展。

OpenLab.Taipei #2 PORTA2030

演講結束後，又跟李駿聊了一番，談到藝術創作者與軟體開發者的差異性。他說 – 創作者的出發點可能只是一個小小的 LED 開關切換，逐漸的發想到各種可能的情境，是由上而下的正三角形。而軟體工程師的思維可能是先發想龐大的可能性，而逐漸收斂成一個規格明確的目的，是由上而下的倒三角形。我倒是認為就新軟體的發展與創新，軟體開發者或所謂 hacker 跟藝術家是一樣的熱於嘗試的，沒有太大差異，差別在於軟體開發者習慣追求一個可以預測的需求目標，而藝術創作者追尋的是模糊的感官經驗。

這種思考習慣，完全會會影響創作的方向與欣賞的態度。就像阿怪所厭惡的「藝術家」，我也一直到現在都無法領會眾多其實只是燈泡開關的裝置意義何在，倒是對以諷刺為出發點得行動藝術或與文化議題掛勾的藝術形式相當喜愛。

就像當初 pingooo 提了洪水的故事情境，PORA2030 的假想情境有一部分是基於發生災難的狀態，在災難發生，通訊系統全毀時的應對措施。雖然說在這種危及的時候，傳統常使用短波業餘無線電或無線對講機來通信，但由於技術的問題，速度與可用性無法因應災區臨時需要傳送數位資訊的需求，若可以臨時搭建一個 IP 網路系統那麼災區就可以更容易的與救災中心交換資訊。事實上，有其他人也想過類似的狀態，如美國的安全專家 W. David Stephenson 就建議可以採用 CUWiN 社群的 Mesh Network 開機光碟。(影片: 21st century disaster tips you won’t hear from officials)

當時的想法是除了透過臨時搭設的 IP 網路系統，除了便利救災人員與總部交換資訊外，若救災人員上攜帶具無線網路功能的行動裝置，也可以透過行動裝置傳送個人資料如經緯度、語音、文字、圖片訊息到指揮團隊。pingooo 當時的意見是可以搭配 Sahana 使用，讓臨時網路可以與介接。

OpenLab.Taipei #2 PORTA2030 Extra

我在演講的結束時，加上了幾張簡報，提到了最近幾位朋友為了 88 水災發起的 Sahana 翻譯推廣，以及志工的徵求狀態。希望這件事情不會再到下次災難發生時才又再被提起。

Updated: 2009/09/01 演講錄影已經上線。

Posted on
by

在朋友的介紹下，知道了法國的 /tmp/lab 正在籌辦 Wireless Battle Mesh 2009。身為一個 OpenWRT 使用者，以及 802.11 Wireless Mesh Networks 的技術評估人員，一直都持續私下地嘗試不同的 Wireless Mesh Network 通訊協定的不同組合，希望能夠找到一組技術本質上最適宜 Urban Wireless Network 使用的方案。除了開放原碼的協定外，也有機會測試一些台灣廠商所自行開發的私有協定。

l1000459-small

Source: http://n0rg.org/wbm2009

不過礙於資源與時間的限制，只能作一些業餘程度的實驗，還沒有機會可以設定起不同的協定做效能評比。很高興可以聽到在法國巴黎，有一群人，實際的選用了三種不同的 Mesh Network 路由協定 OLSR, Batman 與 BABEL，並為三種不同的協定各自設定了 25 個節點進行測試。

其中 OLSR 與 BABEL 都是 Layer 3 mesh protocol，算是單純的 IP-based mesh routing protocol。在這個活動之前，我並不知道關於 BABEL 這個協定的資訊，據聞是巴黎第六大學 (Universite Pierre et Marie Curie, ‘Universite Paris 6’) 的 Juliusz Chroboczek 所開發，比較大的特色是 BABEL 可以同時支援 IPv4/IPv6 dual stack, 不像目前有些 Mesh Protocol 都僅能單獨支援 IPv4 或 IPv6。無法同時支援兩種 IP 協定。如 Batman 在 batman-adv 版本中才支援 IPv6, OLSR 則只能單獨支援 IPv6.

Source: http://n0rg.org/wbm2009

你若曾經研究過幾種不同的 Mesh Network Protocols，應該會知道由於協定的差異與不同演算法實做，常常造成 CPU、記憶體的耗損上有極大的差異，進而影響網路的延展性。另外，由於路由協定考慮的變數不同，有的協定容易造成非常容易斷線的狀態，或者由於考慮變因太多，使的路由的收斂時間變長，甚至因為路由中的黑洞問題，造成路由無窮迴圈。又或者，控制網路的封包過大、過多，結果造成網路上被控制封包佔據，傳輸效能不彰的現象。

即便上述許多現象可以透過演算的方式測試，但是更多時候，若能夠實際的架設一個實驗網絡，是最能夠進行效能校調，以及務實的進行效能評比的了。而 Wireless Battle Mesh 2009 的目的就是如此，為了能夠測試每一種協定的差異，公平的使用同一套 Linux 套件系統(BSP) OpenWRT 與同樣等級的硬體平台。

Source: http://n0rg.org/wbm2009

在 Wireless Battle Mesh 2009 Wiki 上的說明提到，本次測試使用的硬體有 FON Fonera, Linksys WRT54GL, Linksys WRT54GS v4, ASUS WL-HDD25 等。根據小道消息，Batman Adv 的效果比 OLSR 與 BABEL 都好一點，儘管這跟我期待的結果一樣，不過還沒看到數據之前，我自己也還無法信服阿。更多關於 Wireless Battle Mesh 2009 的圖片與影像紀錄可以於此找到。

類似的無線測試計畫，我還注意到柏林自由大學 (Freie Universität Berlin) 的 Distributed Embedded Systems (DES) testbed，目前建制了七十個節點，最終希望建制到一百個點。多種開放原碼的路由協定也都會被置入此測試平台中，目前利用此測試平台所研究的十六篇論文都已經發表在網站上。從DES Testbed 的相關研究一頁，我們看到有許多大學也曾經或正在設置過類似的研究平台。如 Leipzig Wireless Mesh Testbed, USCB MeshNet, UMIC-Mesh.net, 韓國 WiSEMesh(Wireless Scalable and Efficient Mesh network) 等。

其中部份大學的研發動力，也演化成社區的自治無線網路基礎，變成一個更廣大的使用者族群。或是像 MIT 的 Roofnet，脫離學術網路變成獨立的商業公司 Meraki Networks, 將技術商業化到全世界市場，算是相當成功的轉型案例。

另外一個我特別注意的測試系統是 ORBIT Lab (Open-Access Research Testbed for Next-Generation Wireless Networks)，這個系統有趣的是除了設定 20×20 的測試節點陣列，使用者可以利用終端端設定每一個節點要載入測試的作業系統磁碟檔案，也可以透過 API 控制、查詢每個節點的狀況。是我目前見到最先進的測試環境了，先前曾經找過國內的大學、研究機構，都還沒看到有機構投資這樣的測試環境。不愧是美國國家科學基金會花了五百四十五萬美金分四年所投資的 Networking Research Testbeds (NRT) 研究計畫阿。

Posted on
by

在 open80211s 的 mailing list 上看到廣告，今年的 MeshTech 2009 是在澳門舉辦耶，跟著 IEEE MASS 2009 是同一時段 都是在 10 月 5 日至 9 日間舉辦，看似是非常的好的機會認識一些鑽研 Mesh Networks 的學長專家。

從 2007 年開始，Mesh Tech 已經舉辦到第三屆了，第一屆在義大利、第二屆在美國。許多議題都是我個人非常感興趣的，例如上一屆的 Keynote speech 中，Georgia Institute of Technology 的 Ian F. Akyildiz 博士，針對了 Mesh Network Protocols 未來的可能設計方向進行了一段演講 Cross Layer Design in Wireless Mesh Networks。

在這段演講與簡報中，Dr. Akyildiz 先分析了幾個可能對網路造成影響的關鍵因素，

  • Radio Techniques (Directional and smart antennas, MIMO, Multi
  • Multi-radio/multi multi-channel systems, Reconfigurable radios, Cognitive radios)
  • Scalability (throughput degradation)
  • Mesh Connectivity
  • Broadband and QoS
  • Compatibility and Inter-Operability
  • Security
  • Ease of Use

然後再從 Mac Layer (Physical Layer) 的問題，一路往上分析 Data Link Layer, Network Layer 到 Transport Layer。

由於傳統的路由設計很多都是只依照某一層協定來開發或最佳化，如此會簡化牽涉的可能問題，比較容易除錯。但是相對的，由於無法兼顧其他層協定的變數，以至於效能不佳。

例如傳統的路由協定可能會選擇對短路由，但是若無線網路受到干擾，這條路徑並不見得是最佳選擇，反而變成系統中的效能瓶頸。而這種瓶頸，很容易就影響到整個 Wireless Mesh Network 系統的吞吐量衰減值 (throughput degradation)。

依照目前的研究說來，利用異層協定的資訊與 Generalized Network Utility Maximization (NUM) 架構來設計跨層式協定，一定會某種程度的提高網路效能，但是相對的這種協定的會帶來複雜性、互通性、可發展性 (Evolution Capability) 等種種的問題。這些都是研究人員需要考慮的問題。分層式設計 (layered design) 跟跨層式設計 (cross layer design) 還沒有一個孰是孰非的定論。

MeshTech 會議中，我感興趣的還有

Posted on
by

身為一個兼職網管，偶爾你總想找出到底是那一隻程式佔用了網路埠、或是找出某個連線是哪隻程式建立的。在 FreeBSD 上有一個工具非常好用，叫做 sockstat。但是 Linux 過去一直沒有人寫這樣的工具，你可以用 ‘lsof -i -n’ 或是 ‘netstat -anpe‘ 等指令來滿足這個需求。

最近 William Pitcock (nenolod) 重新改寫了一版給 Linux 用的 sockstat，目前已經進入 Debian Sid 中。

需要者請自行取用吧。

Continue reading →