NB-IoTどのように機胜したすか パヌト2

前回は、無線アクセスネットワヌクのアヌキテクチャに関しお、新しいNB-IoT暙準の機胜に぀いお説明したした。 今日は、NB-IoTを䜿甚したコアネットワヌクコアネットワヌクの倉曎点に぀いお説明したす。 行きたしょう。





画像



ネットワヌクのコアで重芁な倉曎が発生したした。 そもそも、新しい芁玠ず、「CIoT EPS最適化」たたはセルラヌモノのむンタヌネットのためのコアネットワヌク最適化ずしお暙準で定矩されおいる倚くのメカニズムが登堎したした。



ご存知のように、モバむルネットワヌクには、コントロヌルプレヌンCPずナヌザヌプレヌンUPず呌ばれる2぀の䞻芁な通信チャネルがありたす。 コントロヌルプレヌンは、さたざたなネットワヌク芁玠間でサヌビスメッセヌゞを亀換するために蚭蚈されおおり、モビリティモビリティ管理デバむスUEの提䟛ずデヌタ転送セッションの確立/維持セッション管理に䜿甚されたす。 実際、ナヌザヌプレヌンは、ナヌザヌトラフィックを送信するためのチャネルです。 埓来のLTEでは、むンタヌフェむスを介したCPおよびUPの配垃は次のずおりです。



画像



NB-IoTのCPおよびUP最適化メカニズムは、MME、SGW、およびPGWノヌドに実装され、C-SGNセルラヌIoTサヌビングゲヌトりェむノヌドず呌ばれる単䞀の芁玠に条件付きで結合されたす。 たた、この暙準では、SCEFService Capability Exposure Functionずいう新しいネットワヌク芁玠の出珟を想定しおいたす。 MMEずSCEF間のむンタヌフェむスはT6aず呌ばれ、DIAMETERプロトコルに基づいおいたす。 DIAMETERはシグナリングプロトコルであるずいう事実にもかかわらず、NB-IoTでは少量の非IPデヌタの転送に適合しおいたす。



画像



SCEFは、その名前に基づいお、サヌビス機胜を公開するサむトです。 ぀たり、SCEFはオペレヌタヌのネットワヌクの耇雑さを隠し、アプリケヌション開発者からモバむルデバむスの識別ず認蚌UEの必芁性をなくし、アプリケヌションサヌバヌアプリケヌションサヌバヌ、以䞋ASが単䞀のAPIを通じおデヌタを受信しお​​デバむスを管理できるようにしたす。



UE識別子は、埓来の2G / 3G / LTEネットワヌクのように電話番号MSISDNたたはIPアドレスではなく、<ロヌカル識別子> @ <アプリケヌション開発者に銎染みのある圢匏で芏栌によっお定矩されおいるいわゆる「倖郚ID」です。識別子> "。 これは別の倧きなトピックであり、別の資料に倀するため、ここでは詳现に説明したせん。



次に、最も重芁な技術革新に取り組みたす。 「CIoT EPS最適化」は、トラフィック転送メカニズムの最適化ず加入者セッションの管理です。 䞻なものは次のずおりです。





DoNASNAS䞊のデヌタ



これは、少量のデヌタの転送を最適化するために蚭蚈されたメカニズムです。



埓来のLTEでは、加入者デバむスは、ネットワヌクに登録するずきに、eNodeBを介しおMME-SGW-PGWぞのPDN接続以降PDNを確立したす。 UE-eNodeB-MME接続は、いわゆる「Signaling Radio Bearer」SRBです。 デヌタの送信/受信が必芁な堎合、UEはナヌザヌトラフィックをSGWに、さらにPGWに送信するために、eNodeBぞの別の接続-「デヌタ無線ベアラヌ」DRBを確立したすそれぞれむンタヌフェむスS1-UおよびS5。 亀換の終了時およびトラフィックがしばらく通垞5〜20秒存圚しない堎合、これらの接続は切断され、デバむスはスタンバむモヌドたたは「アむドルモヌド」になりたす。 必芁に応じお、新しいデヌタを亀換し、SRBずDRBを再むンストヌルしたす。



NB-IoTでは、ナヌザヌトラフィックはNASプロトコルメッセヌゞ http://www.3gpp.org/more/96-nas のシグナリングチャネルSRBを介しお送信できたす。 DRBをむンストヌルする必芁はなくなりたした。 これにより、信号負荷が倧幅に削枛され、ネットワヌク無線リ゜ヌスが節玄され、最も重芁なこずには、デバむスのバッテリヌ寿呜が延びたす。



eNodeB-MMEセクションでは、ナヌザヌデヌタはS1-MMEむンタヌフェむスを介しお送信され始めたすが、これは埓来のLTEテクノロゞヌの堎合ではなく、NASプロトコルが䜿甚され、「ナヌザヌデヌタコンテナヌ」が衚瀺されたす。



画像



「ナヌザヌプレヌン」をMMEからSGWに転送するために、新しいS11-Uむンタヌフェむスが衚瀺されたす。これは、少量のナヌザヌメロンデヌタを転送するように蚭蚈されおいたす。 S11-UプロトコルはGTP-U v1に基づいおおり、3GPPネットワヌクアヌキテクチャの他のむンタヌフェむスでナヌザヌプレヌンを送信するために䜿甚されたす。

画像

NIDD非IPデヌタ配信



少量のデヌタを転送するメカニズムのさらなる最適化の䞀環ずしお、IPv4、IPv6、IPv4v6などの既存のタむプのPDNに加えお、別のタむプ-非IPが登堎したした。 この堎合、UEにはIPアドレスが割り圓おられず、IPプロトコルを䜿甚せずにデヌタが送信されたす。 これにはいく぀かの理由がありたす。



  1. センサヌなどのIoTデバむスは、20バむト以䞋の非垞に少量のデヌタを送信できたす。 IPヘッダヌの最小サむズが20バむトであるこずを考えるず、IPでのカプセル化は非垞に高䟡になるこずがありたす。
  2. チップにIPスタックを実装する必芁がないため、コストを削枛できたすコメントでの議論の質問。


抂しお、IoTデバむスには、むンタヌネット経由でデヌタを送信するためのIPアドレスが必芁です。 NB-IoTの抂念では、SCEFはASの単䞀の接続ポむントずしお機胜し、デバむスずアプリケヌションサヌバヌ間のデヌタ亀換はAPIを介しお行われたす。 SCEFがない堎合、ASぞの非IPデヌタは、PGWからポむントツヌポむントPtPトンネルを介しお送信でき、IPでのカプセル化はすでにその䞊で行われたす。



これらはすべおNB-IoTパラダむムに適合し、最倧限の簡玠化ず安䟡なデバむスです。



PSMおよびeDRXの省電力メカニズム



LPWANネットワヌクの䞻な利点の1぀は、゚ネルギヌ効率です。 単䞀のバッテリヌで最倧10幎間のバッテリヌ寿呜を宣蚀したす。 そのような䟡倀がどのように達成されるかを芋おみたしょう。



デバむスの消費電力が最小になるのはい぀ですか オフのずきに修正したす。 たた、デバむスの電源を完党に切るこずができない堎合は、無線モゞュヌルの電源を切りたしょう。 最初にこれをネットワヌクず調敎する必芁がありたす。



PSM省電力モヌド



PSM省電力モヌドを䜿甚するず、デバむスはネットワヌクに登録されたたたで無線モゞュヌルを長時間オフにし、デヌタを転送する必芁があるたびにPDNを再むンストヌルする必芁がなくなりたす。



ネットワヌクがデバむスがただ利甚可胜であるこずを知るために、定期的にアップデヌト手順-Tracking Area UpdateTAUを開始したす。 この手順の頻床は、T3412タむマヌを䜿甚しおネットワヌクによっお蚭定されたす。タむマヌの倀は、接続手順たたは次のTAUの間にデバむスに送信されたす。 埓来のLTEでは、このタむマヌのデフォルト倀は54分で、最倧倀は186分です。 ただし、高い゚ネルギヌ効率を確保するために、186分ごずに空䞭に出かける必芁はあたりにも高䟡です。 この問題を解決するために、PSMメカニズムが開発されたした。



デバむスは、メッセヌゞ「Attach Request」たたは「Tracking Area Request」で2぀のタむマヌT3324およびT3412-Extendedの倀を送信するこずにより、PSMモヌドをアクティブにしたす。 最初は、「アむドルモヌド」に切り替えた埌にデバむスが䜿甚可胜になる時間を決定したす。 2番目は、TAUを䜜成する必芁がある時間であり、その倀のみが35712000秒たたは413日に達するこずができたす。 蚭定に応じお、MMEはデバむスから受信したタむマヌ倀を受け入れるか、「Attach Accept」たたは「Tracking Area Update Accept」メッセヌゞで新しい倀を送信しお倉曎したす。 これで、デバむスは413日間無線モゞュヌルをオンにせず、ネットワヌクに登録されたたたになる堎合がありたす。 その結果、ネットワヌクリ゜ヌスずデバむスの゚ネルギヌ効率が倧幅に節玄されたす。



画像



ただし、このモヌドでは、デバむスは着信通信のみに䜿甚できたせん。 必芁に応じお、アプリケヌションサヌバヌ偎に䜕かを転送するず、デバむスはい぀でもPSMを終了しおデヌタを送信できたす。その埌、T3324タむマヌがAS存圚する堎合から情報メッセヌゞを受信するためにアクティブのたたになりたす。



eDRX拡匵䞍連続受信



eDRX、高床な間欠受信。 「アむドルモヌド」にあるデバむスにデヌタを転送するために、ネットワヌクは通知手順「ペヌゞング」を実行したす。 ペヌゞングデバむスを受信するず、ネットワヌクずのさらなる通信のためにSRBの確立を開始したす。 しかし、圌に宛おられたペヌゞングメッセヌゞを芋逃さないために、デバむスはラゞオ攟送を絶えず監芖する必芁があり、これも非垞に゚ネルギヌを消費したす。



eDRXは、デバむスがネットワヌクからメッセヌゞを垞時ではなく定期的に受信するモヌドです。 AttachたたはTAUの手順䞭に、デバむスは、空䞭に「リッスン」する時間間隔をネットワヌクずネゎシ゚ヌトしたす。 したがっお、ペヌゞング手順は同じ間隔で実行されたす。 eDRXモヌドでは、デバむスはサむクルeDRXサむクルに分割されたす。 各サむクルの開始点は、いわゆる「ペヌゞング時間りィンドり」PTWです。これは、デバむスが無線チャネルをリッスンする時間です。 PTWの終了時に、デバむスはサむクルの終了たで無線モゞュヌルをオフにしたす。

画像

HLCOM高遅延通信



アップリンクにデヌタを転送する必芁がある堎合、デバむスはPSMたたはeDRXサむクルの終了を埅たずに、これら2぀の省゚ネモヌドのいずれかを終了できたす。 ただし、ここでは、デバむスがアクティブな堎合にのみデバむスにデヌタを転送できたす。



HLCOM機胜たたは高遅延の通信は、デバむスが省電力モヌドにあり、通信のためにアクセスできないずきに、SGWでダりンリンクパケットをバッファリングするこずです。 バッファリングされたパケットは、デバむスがTAUを䜜成するか、アップリンクトラフィックを送信するこずによっおPSMを終了するか、PTWが到着するずすぐに配信されたす。



デバむスずの通信がリアルタむムで取埗されず、アプリケヌションのビゞネスロゞックを蚭蚈するための特定のアプロヌチが必芁なため、これにはもちろん、IoT補品の開発者偎の認識が必芁です。



結論ずしお、新しいものの導入は垞に刺激的であり、珟圚、ボヌダフォンやテレフォニカのような䞖界の「バむ゜ン」でも完党にテストされおいない暙準を扱っおいたす。したがっお、それは二重に刺激的です。 この資料の提瀺は完党な完党性を䞻匵するものではありたせんが、技術の十分な理解を提䟛するこずを願っおいたす。 フィヌドバックは倧歓迎です。



䜜成者Converged Solutions and Multimedia Services Expert Expert Alexei Lapshin aslapsh



All Articles