LPWAN方案商是否該為衛星物聯網感到驚慌失措?

2021-10-01 01:20:24 字數 2674 閱讀 1697

對比來看,衛星物聯網將很可能成為低功耗廣域網的一種競爭性方案,一不小心,新的玩家就已經悄然入局!

近日,筆者在衛星物聯網上看到這樣一則訊息:總部位於溫哥華的helios wire計畫將30顆衛星發射到太空中,其頻寬足以監測地球上50億個感測器,此舉將徹底打亂物聯網的成本結構。

helios翻譯過來是太陽神的意思,和這個雄心壯志的名字一樣, helios計畫也顯得野心勃勃:在2023年將兩顆低成本衛星發射到軌道上,並在未來三年內發射大約28顆衛星——所有這些都小於1億美元,估計基礎設施投資數十億美元。據說,屆時監控成本可能低於1美元/月 ——是目前典型物聯網服務費用的幾分之一。

看到這裡,筆者心裡登時乙個激靈,低功耗廣域網路領域是不是要有新的競爭者入局了?

helios wire是何方神聖?

helios wire是誰?聽起來非常陌生,從僅有的少數資料裡,我們可以了解到:helios目前還是乙個初創企業,擁有五個聯合創始人和100萬美元的種子資金。

它的創始人兼首席執行官斯科特·拉森正是當初那個在國際空間站的俄羅斯模組上免費安裝高畫質攝像頭的人,沒錯,即那個衛星創業領域的明星公司urthecast——該公司在國際空間站的俄羅斯轄區安裝了兩台高解析度攝像機(1m和6m),實現了對地球表面的長期監測,在監測環境、人道主義救助、社會活動以及農業土地等領域開展了業務。

helios wire正在為那些需要低頻寬和低服務成本的物聯網應用程式設計和構建衛星物聯網/m2m服務。helios系統將針對現有和新興的物聯網/m2m應用程式,包括在交通、消費、物流、安全/公共安全、能源、工業、動物管理和農業等各個行業中對固定和移動資產進行監控和控制。

計畫中的helios網路將使用30 mhz的s波段頻譜,用其衛星接收來自數十億個地球感測器的微小資料報,然後將資料傳回地面。s波段頻譜非常適合短資料,它將允許衛星物聯網連線大量的裝置。

該系統特別適合於監測偏遠或遠距離移動的物體, 前兩顆衛星每天只能接收和中繼三次資料,因此需要更頻繁的資料傳送的應用(如運輸物流)將不得不等待。

突然入局的低功耗廣域網(lpwan)競爭者?

我們總結一下helios網路的特點:

1.使用30 mhz的s波段頻譜,非常適合短資料——低頻寬、低功耗

2.28顆衛星足夠監測全球50億個感測器,大大滿足物聯網裝置的連線需求——大數量級

3.特別適用於監測偏遠或遠距離移動的物體——廣覆蓋

4.能中繼的資料次數有限,暫時無法滿足頻繁傳送資料的需求——低頻率,適合感測器資料採集等應用場景

怎麼樣?是不是很眼熟??

在筆者以前推送的多篇論述lora、nb-iot等低功耗廣域網的文章中,都對lpwan技術做了類似的描述。

從距離角度來看,就像當前3g/4g一張無處不在的蜂窩網路一樣,未來運營商級的低功耗廣域網路將是整個城市甚至國家廣覆蓋的一張大網。與藍芽和zigbee相比,由於lpwan網路廣覆蓋、穿透性強的特徵,無處不在的網路可以讓各類低功耗裝置隨時接入,連那些深埋在地下的管網和各種角落的計量表都可以實現覆蓋和連線。從功耗角度來看,lpwan具有更低功耗,對於一些電池供電的裝置來說,數年甚至十幾年都無需更換電池。當然,功耗與傳輸速率不可兼得,獲得這樣的功耗表現,需付出超低資料頻寬的代價。

這樣對比看來,衛星物聯網將很可能成為低功耗廣域網的一種競爭性方案。一不小心,新的玩家就已經悄然入局。

其實,最近在衛星物聯網領域有動靜不只這一家,就在前幾天。

全球電信巨頭沃達豐宣布與人造衛星**商inmarsat(國際海事衛星組織)就全球衛星連線達成合作,這一舉措將進一步推進物聯網的發展。

漫遊協議包含對inmarsat i-4衛星網路的使用,該網路提供了覆蓋所有天氣條件的長波段。這意味著固話和移動連線將從地面網延伸至各行各業,以適應農業、公共事業、石油天然氣、運輸等各行業的需求。

lpwan方案商應該為此驚慌失措嗎?

乙個最主要的問題是,衛星物聯網方案會和現有的nb-iot、lora等lpwa解決方案形成競爭嗎?

答案是肯定的,畢竟應用場景上有很多相似和重合之處,但是lpwan也不用為此驚慌失措,援引中科院計算機網路資訊中心吳雙力博士的觀點,主要有三點原因導致衛星物聯網的競爭力十分有限。

1.衛星物聯網無法解決室內裝置的資料採集問題

就拿gps微波訊號來說,它的穿透能力差,衰減的很厲害。所有金屬實體會完全這比gps訊號,玻璃和塑料有輕度衰減,厚重的非金屬物體比如幾厘公尺的木頭或者牆壁都會遮蔽訊號。

這就導致室內幾乎無法接收衛星訊號,想用衛星物聯網採集室內裝置的資料也就是天方夜譚。但是nb-iot、lora等技術都有很強的穿透性,厚厚的牆壁和地面完全不成問題。

2.衛星物聯網的應用場景有限

衛星物聯網畢竟是天上的系統,和lpwan比起來還是不夠「接地氣」。

地面網比如nb-iot、lora可以通過網路優化、訊號增強、密集的建設基站來實現無縫覆蓋,而衛星一共就能發射那麼幾十個,軌道也是大問題,想實現全球範圍的覆蓋還是困難重重。而且衛星訊號本身要求資料傳輸的低速率、低頻率,應用場景有限。

3.衛星物聯網的產業鏈還很不成熟

第三點也是最重要的一點,就是衛星物聯網的產業鏈十分不成熟。現階段只是把衛星送上天去,但是要想真正實現應用,據必須要求配套的衛星物聯網晶元和模組,現實卻是要啥沒啥。

與之相比,nb-iot、lora等技術已經有了比較成熟的產業生態系統,甚至已經或即將商用,而衛星物聯網現在想做前期的推廣恐怕都十分苦難。

但需要警惕的是,衛星物聯網並不是只有大公司或者資金雄厚的國企才能做,乙個幾十公斤種的低軌衛星成本並不高昂,只要能解決軌道和傳輸頻段問題,實現衛星物聯網也並非天方夜譚。

未來這個領域將會怎樣發展,還需拭目以待。

是否應該為技術債建立使用者故事?

敏捷團隊有時也會為純技術性任務而掙扎,比如必須處理技術債。雖然這種任務對系統使用者沒有直接價值,但要交付可以工作的軟體又不得不處理。那麼,是不是應該建立使用者故事來應對這樣的技術性任務或技術債呢?在博文 像 作為開發者 這樣的表達並非使用者故事 中,bill wake談到了他所遇到的對客戶沒什麼價值...

建構函式和析構函式是否應該為虛函式

建構函式不能是虛函式。因為建立派生類的物件時,將呼叫派生類的建構函式,而不是基類的建構函式,然後,派生類的建構函式將使用基類的乙個建構函式,這種順序不同於繼承機制。因此,派生類不繼承基類的建構函式,所以將類建構函式宣告為虛的沒什麼意義。析構函式應該是虛函式,除非類不用做基類。例如當e為基類,s是派生...

是否首次進入頁面判斷方案

需求進入 1.進入a頁面,輸入一些資訊後,跳轉b頁面選人,然後攜帶使用者資訊回到a。a中所有內容都保留,且攜帶回b頁面選的人。2.每次從新進入a頁面,a頁面重新整理。解決方案 進入a頁面時,直接replace跳轉當前url拼接乙個時間戳引數。ts 當前時間。使用者不會有跳轉感知,瀏覽器裡也不會多一層...