NB-IoT要不要走運營商平臺？（第一期）

不走運營商平臺，在eDRX技術和PSM模式下，數據是否能下發？

不走運營商平臺，在eDRX技術和PSM模式下，數據是否能下發？

01

NB-IoT有別于傳統的2G網絡，增加了eDRX和PSM兩個關鍵性技術。也因為這兩個關鍵技術的引入，讓NB-IoT一躍成為IoT的主要通信方式之一。

02

先簡單的了解一下NB-IoT有三種狀態：（引入程序員和BUG的故事）

Connect狀態

Connect比較容易理解，就像程序員在“碼”不停蹄的編寫“BUG”（NB終端和基站核心網一直保持通信狀態，平臺隨時可以把數據傳輸給終端UE）。

IDLE狀態

程序員寫完“BUG”，放下鍵盤盯著屏幕，一旦“BUG”運行有問題，立刻恢復到寫“BUG”狀態。對于UE終端而言，IDLE是空閑監聽態，一旦平臺端有數據傳輸，立刻切換成Connect模式。

那么加上eDRX技術后，就是讓寫完BUG后的程序員還能和同事吹會兒牛，當然也不能只顧著吹牛，還是要按時的看看BUG運行情況。

PSM狀態

PSM就更放肆（漂亮）了，讓程序員寫完一個BUG后，直接下班，第二天回到公司后看BUG運行狀態。遠離996，擁抱PSM。

03

回到這個話題本質，在eDRX（DRX）的休眠（程序員吹牛）期間，平臺(不指運營商平臺)發送的消息（BUG報錯）是否能通知到終端（程序員）？答案是：可以的。

在終端休眠期間，如果云端有數據回傳下發，此時數據先緩存在核心網，一旦eDRX終端切換到“尋呼態”，核心網將數據發送至NB-IoT終端，即使云端在NB-IoT終端接到數據前關閉此鏈路，這個數據依舊會先發到NB-IoT終端，然后再執行關閉鏈路。

04

那是不是我就可以不用運營商平臺就能實現下發了？先不要高興的太早！

端口老化？對了，就是這個問題。

我們都知道在IPV4時代的NAT轉發，即使不知道，它也在我們的身邊形影不離。因IPV4的IP資源枯竭，實際運營商給我們上分配到的地址，大多是內網地址，一旦是內網地址就會存在端口老化問題。

如NB-IoT終端所獲取到的是100.x.x.x，正是局域網地址，而此時終端想發送數據給外界（如云端），就必須先通過NAT轉發將數據偽裝成運營商公用的公網地址，在進行通信。

好比：程序員想要采購，必須要找采購專員一樣，當然采購專員不是只為某個人服務的。

那么接收呢？接收就和我們使用的鏈路協議有關，當前的國內的蜂窩網絡中，TCP的鏈路NAT保活大約是300s左右。也就是說在300s內，我們是可以通過云端直接下發數據給終端，而想實時實時存活，就必須在300s以內激活此NAT轉發。

而UDP的鏈路就沒有TCP那么幸運了，UDP在15s左右就會被運營商關閉此NAT轉發。而我們NB-IoT最常用的LWM2M就是基于UDP協議，所以非運營商平臺，想遠程下發數據，基本是不太現實的。

那么運營商是怎么平臺是怎么做到的呢？做法比較粗暴，運營商的服務器搭建在100段的局域網內，直接繞過NAT轉發。

但是，我們就沒有其他選擇了嗎？NO...NO...NO...

先請各位放下手中的刀和錘子先別，小編只是想從技術層面告訴大家事實。

05

那我是不是就不能自建平臺？別急，小編想告訴你的是：自建平臺也是可以的。

網站 TCP/IP IoT

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。