<p id="1tkge"></p>
  1. <td id="1tkge"><option id="1tkge"></option></td>
    1. <track id="1tkge"><strike id="1tkge"><b id="1tkge"></b></strike></track>
        <table id="1tkge"><ruby id="1tkge"></ruby></table>
        <acronym id="1tkge"></acronym>
      1. <table id="1tkge"></table>
            今天是:   歡迎訪問通信維護技術行業的門戶網站!  
            設為首頁
            加入收藏
            網站地圖
            首頁 > 通信技術 > 網絡優化 >
            分享到: 收藏

            NB-IoT核心網
            2018-05-08 11:23:54   來源:   評論:0 點擊:

            大家都知道的,盡管LTE和NB-IoT一脈同氣,但LTE的設計目標是高速率、大流量,而NB-IoT為物聯網“間歇傳送小數據”而生,兩者方向相反。因此,LTE核心網EPS也不再適應NB-IoT應用,需要對其進行優化。

              大家都知道的,盡管LTE和NB-IoT一脈同氣,但LTE的設計目標是高速率、大流量,而NB-IoT為物聯網“間歇傳送小數據”而生,兩者方向相反。因此,LTE核心網EPS也不再適應NB-IoT應用,需要對其進行優化。

             

            為了提升NB-IoT系統的小數據的傳輸效率,3GPP SA2工作組于2015年7月開始研究CIoT EPS優化構架,提出了CIoT EPS需支持四大功能:
            ①支持超低功耗物聯網終端
            ②支持每小區連接大量物聯網設備
            ③支持窄帶頻譜無線接入技術
            ④支持物聯網增強覆蓋

            并進行功能簡化,裁剪了LTE EPS的四項功能:
            ①不提供緊急呼叫服務
            ②不支持流量卸載,如本地lP接入(LIPA)和選擇性IP流量卸載
            ③在EPS連接管理上,只支持IDLE模式下的重選,不支持CONNECTED模式下的切換
            ④不支持建立GBR承載和專用承載

            最終,3GPP提出了兩種優化方案:控制面優化傳輸方案( C-Plane CIoT EPS optimization)和用戶面優化傳輸方案(U-Plane CIoT EPS optimization)。對于物聯網終端,必須支持“控制面優化傳輸方案”,可選支持“用戶面優化傳輸方案”。

             控制面優化傳輸方案

              控制面優化傳輸方案使得小數據包可以傳輸于控制面上,數據以非接入層協議數據單元(NAS PDU)的格式封裝于控制面信令消息來傳輸,其概念如同商場購物,若消費者只購買少量商品,可經由指定的快速通道結賬。這一方案可在傳輸數據時減少了控制面信令開銷,因此有助于降低終端功耗和減少使用頻帶。

              如上圖所示,控制面優化傳輸方案支持IP數據和非IP數據傳輸,傳輸路徑可分為兩條:①通過S-GW傳送到P-GW再傳送到應用服務器(CIoT Services);②通過SCEF(Service Capability Exposure Function)連接到應用服務器,該路徑僅支持非IP數據傳輸。

            根據傳輸路徑和是否支持IP數據傳輸,可分為三種傳輸模式:

            傳輸路徑①(IP數據傳輸)

            傳輸路徑為S-GW到P-GW再到應用服務器,可沿用現有的IP通信技術快速部署NB-IoT,缺點是安全性低,且不經過SCEF,電信運營商仍為管道角色。

            傳輸路徑①(非IP數據傳輸)

            傳輸路徑仍為S-GW到P-GW再到應用服務器,但由于已無IP地址傳輸數據包,因此在P-GW上必須要有NB-IoT終端的ID與AS的IP地址+端口號的對應關系,才能將數據包正確傳送在SGi的界面上,這種方式稱為UDP/IP的點對點隧道(Point-to-Point (PtP) Tunneling)技術。隧道的參數,也就是目的地IP地址與UDP端口號需事先配置于P-GW上,對NB-IoT終端和AS之間傳送的數據來說,P-GW是一個透明的傳輸節點。

            這種方式安全性高且省電,但需要開發新的點對點隧道技術。

            傳輸路徑②(非IP數據傳輸)

            即通過SCEF傳遞Non-IP數據,這條路徑僅支持非IP數據傳輸,屬于Non-IP專屬解決方案。這種方式優點較多,安全性高、省電,且運營商能創造新的商業價值,但需新建SCEF網元節點,需開發新的API技術。

            SCEF

            SCEF為NB-IoT新增加的節點,其通過API接口向AS提供服務,而非直接發送數據,使得電信營運商不再只是管道,而是可以將業務能力安全地開放給第三方業務供應商,實現對物聯網的大數據分析以創造新的商業價值。

             

              SCEF構架如上圖所示,鑒于安全性考慮,SCEF放置于運營商信任的網域中(Trust Domain),并通過OMA(Open Mobile Alliance),GSMA(Groupe Speciale Mobile Association),或其他標準組織(Standardisation Bodies, SDOs)的API接入服務,同時,SCEF的API支持多種不同類型,如DIAMETER、RESTful APIs與XML over HTTP等,使得SCEF可以更靈活應用于不同的網絡中。Network Entity則指HSS、MME、P-GW、PCRF或與計費、安全相關的網絡節點。

            C-SGN

              C-SGN,即CIoT Serving Gateway Node,是控制面優化傳輸方案引入的新節點,該節點是由LTE EPS的控制面節點MME、用戶面節點S-GW和P-GW的最小化功能合并而成的單個邏輯實體,C-SGN功能也可以部署在現網EPS的MME中。

            HLCom

              在控制面優化傳輸方案中,可引入了HLCom機制,即Optimization to support High Latency Communication,該機制將下行數據緩存在S-GW中。由于NB-IoT終端通過PSM和eDRX等技術來間歇性接收數據,以達到省電的目的,當NB-IoT終端在休眠狀態時,S-GW將下行數據緩存,直到終端被喚醒后才將這些緩存的數據下發給終端。

            用戶面優化傳輸方案

              數據傳輸的方式與LTE EPS一樣采用用戶面承載,但是,該優化方案在RRC層引入了掛起(Suspend)和恢復(Resume)兩種新狀態以適應物聯網數據的間歇傳輸特性,同時要求NB-IoT終端、eNB和MME存儲連接信息,以快速恢復重建連接,簡化信令流程,提升傳輸效率。

             

              經過這么一優化,承載可以按需的方式建立,因而可降低終端功耗和支持單小區大規模物聯網設備連接。該方案除了支持現有EPS功能外,還可以支持通過P-GW傳輸非IP數據。

            RRC Suspend流程

             

            如上圖所示,該過程由eNB激活,釋放NB-IoT終端與eNB之間的RRC連接,以及eNB與S-GW之間的S1-U承載。

            步驟(1)和(2):
            eNB發送UE Context Suspend Request,并通過MME向S-GW發起釋放與NB-IoT終端相關的承載信息。

            步驟(3):
            S-GW釋放eNB與NB-IoT終端相關的S1-U承載。具體而言,S-GW僅釋放eNB地址和下行隧道端點標識符(TEID),并繼續存儲其他信息。

            步驟(4)和(5):
            在S-GW處完成S1-U承載釋放后,eNB通過MME接收UE Context Suspend Response通知。

            步驟(6)和(7):
            eNB存儲NB-IoT終端的Access Stratum (AS)信息、S1-AP連接信息和承載信息,并向NB-IoT終端發送RRC Connection Suspend消息。

            步驟(8):
            MME為NB-IoT終端存儲S1-AP連接信息和承載信息,并進入IDLE狀態。

            步驟(9):
            當接收到來自eNB的RRC Connection Suspend消息后,NB-IoT終端存儲AS信息,并IDLE狀態。

            RRC Resume流程

             

            如上圖所示,該過程重新建立(恢復)處于Suspend狀態的NB-IoT UE與eNB之間的RRC連接,以及eNB與S-GW之間的釋放的S1-U承載。Resume過程由NB-IoT啟動和激活。

            步驟(1)和(2):
            首先使用由RRC Suspend過程中存儲的AS信息來恢復與網絡的連接。

            步驟(3):
            此時,eNB對NB-IoT終端執行安全檢查,并向NB-IoT終端提供恢復的無線承載列表,且同步NB-IoT UE和eNB之間的EPS承載狀態。

            步驟(4):
            eNB向MME發送UE Context Resume Request,以通知其與NB-IoT終端的連接已經安全地恢復。

            步驟(5)和(6):
            從eNB接收到該恢復通知后,MME恢復NB-IoT終端的S1-AP連接信息和承載信息,進入CONNECTED狀態,并向eNB發送UE Context Resume Response消息(包括S-GW地址和S1-AP連接信息)。

            步驟(7):
            現在NB-IoT終端可以向S-GW發送上行數據。

            步驟(8 )和(9):
            MME通過Modify Bearer Request消息向S-GW發送eNB地址和下行鏈路TEID,以重建NB-IoT終端與S-GW之間的下行鏈路的S1-U承載。

            步驟(10)和(11):
            S-GW向MME發送Modify Bearer Response消息,然后開始傳輸下行數據。

            值得一提的是,當S-GW接收到下行數據的同時NB-IoT終端處于Suspend狀態,此時,S-GW將緩存數據包,同時在S-GW和MME之間初始化Downlink Data Notification過程,然后MME尋呼NB-IoT終端,由此通過NB-IoT終端啟動激活連接Resume流程。

            相關熱詞搜索:核心 NB-IoT

            上一篇:ONU、機頂盒、路由器常見問題及處理方法
            下一篇:不同場景下的LTE RF優化實戰經驗總結

            无码免费的毛片基地
              <p id="1tkge"></p>
            1. <td id="1tkge"><option id="1tkge"></option></td>
              1. <track id="1tkge"><strike id="1tkge"><b id="1tkge"></b></strike></track>
                  <table id="1tkge"><ruby id="1tkge"></ruby></table>
                  <acronym id="1tkge"></acronym>
                1. <table id="1tkge"></table>