NB-IoT: どのように機能するのですか? パート 3: SCEF – オペレーター サービスへのアクセスの単一ウィンドウ

記事の中で」NB-IoT: どのように機能するのですか? パート2」では、NB-IoTネットワークのパケットコアのアーキテクチャについて、新しいSCEFノードの登場について触れました。 第三部では、それが何なのか、そしてなぜそれが必要なのかを説明します。

M2M サービスを作成するとき、アプリケーション開発者は次の質問に直面します。

• デバイスを識別する方法。
• どのような検証および認証アルゴリズムを使用するか。
• デバイスと対話するためにどのトランスポート プロトコルを選択するか。
• データをデバイスに確実に配信する方法。
• 彼らとデータを交換するためのルールをどのように整理して確立するか。
• オンラインで自分の状態を監視し、情報を入手する方法。
• デバイスのグループに同時にデータを配信する方法。
• XNUMX つのデバイスから複数のクライアントにデータを同時に送信する方法。
• デバイスを管理するための追加のオペレーター サービスへの統合アクセスを取得する方法。

これらを解決するには、独自の技術的に「重い」ソリューションを作成する必要があり、これが人件費の増加とサービスの市場投入までの時間の増加につながります。 ここで、新しい SCEF ノードが役に立ちます。

3GPP で定義されているように、SCEF (サービス機能公開機能) は 3GPP アーキテクチャのまったく新しいコンポーネントであり、その機能は 3GPP ネットワーク インターフェイスによって提供されるサービスと機能を API を通じて安全に公開することです。

簡単に言うと、SCEF はネットワークとアプリケーション サーバー (AS) の間の仲介者であり、直観的で標準化された API インターフェイスを通じて NB-IoT ネットワーク内の M2M デバイスを管理するためのオペレーター サービスにアクセスする単一のウィンドウです。

SCEF は通信事業者のネットワークの複雑さを隠し、アプリケーション開発者がデバイスと対話するための複雑なデバイス固有のメカニズムを抽象化できるようにします。

SCEF API は、ネットワーク プロトコルをアプリケーション開発者にとって使い慣れた API に変換することで、新しいサービスの作成を容易にし、市場投入までの時間を短縮します。 新しいノードには、モバイルデバイスの識別/認証機能、デバイスとAS間のデータ交換ルールの定義機能も含まれており、アプリケーション開発者がこれらの機能を実装する必要がなくなり、これらの機能をオペレータの肩に移すことができます。

SCEF は、アプリケーション サーバーの認証と認可、UE モビリティの維持、データ転送とデバイスのトリガー、追加サービスへのアクセス、およびオペレーター ネットワーク機能に必要なインターフェイスをカバーします。

AS に対しては、8GPP によって標準化された API (HTTP/JSON) である単一の T3 インターフェイスがあります。 T8 を除くすべてのインターフェイスは、DIAMETER プロトコルに基づいて動作します (図 1)。

T6a – SCEF と MME 間のインターフェイス。 モビリティ/セッション管理手順、非 IP データの送信、監視イベントのプロビジョニング、およびそれらに関するレポートの受信に使用されます。

S6t – SCEF と HSS 間のインターフェイス。 サブスクライバ認証、アプリケーション サーバーの認可、外部 ID と IMSI/MSISDN の組み合わせの取得、監視イベントのプロビジョニング、およびそれらに関するレポートの受信に必要です。

S6m/T4 – SCEF から HSS および SMS-C へのインターフェイス (3GPP は、NB-IoT ネットワークでのデバイスのトリガーと SMS 送信に使用される MTC-IWF ノードを定義します。ただし、すべての実装で、このノードの機能はSCEF なので、回路を簡略化するために、別途考慮しません)。 SMS の送信および SMS センターとの通信のためのルーティング情報を取得するために使用されます。

T8 – SCEF とアプリケーション サーバーとの対話用の API インターフェイス。 制御コマンドとトラフィックの両方がこのインターフェイスを介して送信されます。

*実際にはさらに多くのインターフェイスがありますが、ここでは最も基本的なものだけをリストします。 完全なリストは 3GPP 23.682 (4.3.2 参照点のリスト) に記載されています。

SCEF の主な機能とサービスは次のとおりです。

• SIM カード識別子 (IMSI) を外部 ID にリンクする。
• 非 IP トラフィック (非 IP データ配信、NIDD) の送信。
• 外部グループ ID を使用したグループ操作。
• 確認付きデータ送信モードのサポート。
• MO (Mobile Originated) および MT (Mobile Terminated) データのバッファリング。
• デバイスとアプリケーションサーバーの認証と認可。
• 複数の AS による XNUMX 台の UE からのデータの同時使用。
• 特殊な UE ステータス監視機能 (MONTE – 監視イベント) のサポート。
• デバイスのトリガー。
• 非 IP データ ローミングを提供します。

AS と SCEF 間の対話の基本原理は、いわゆるスキームに基づいています。 サブスクリプション。 特定の UE の SCEF サービスにアクセスする必要がある場合、アプリケーション サーバーは、要求されたサービスの特定の API にコマンドを送信してサブスクリプションを作成し、応答として一意の識別子を受信する必要があります。 その後、このサービスのフレームワーク内での以降のすべてのアクションと UE との通信は、この識別子を使用して行われます。

外部 ID: ユニバーサルデバイス識別子

SCEF を介して動作する場合の AS とデバイス間の対話スキームにおける最も重要な変更の 2 つは、ユニバーサル ID の出現です。 従来の 3G/XNUMXG/LTE ネットワークの場合と同様に、電話番号 (MSISDN) や IP アドレスの代わりに、アプリケーション サーバーのデバイス識別子が「外部 ID」になります。 アプリケーション開発者に馴染みのある形式で標準で定義されています。 @ 」

開発者はデバイス認証アルゴリズムを実装する必要がなくなり、ネットワークがこの機能を完全に引き継ぎます。 外部 ID は IMSI に関連付けられているため、開発者は特定の外部 ID にアクセスすると、特定の SIM カードと通信することを確認できます。 SIM チップを使用すると、外部 ID が特定のデバイスを一意に識別するため、完全にユニークな状況が得られます。

さらに、複数の外部 ID を XNUMX つの IMSI にリンクできます。外部 ID が特定のデバイス上の特定のサービスを担当する特定のアプリケーションを一意に識別する場合、さらに興味深い状況が発生します。

グループ識別子、つまり個別の外部 ID のセットを含む外部グループ ID も表示されます。 SCEF への XNUMX つのリクエストで、AS はグループ操作を開始できるようになり、単一の論理グループにまとめられた複数のデバイスにデータまたは制御コマンドを送信できます。

AS 開発者にとって、新しいデバイス識別子への移行は即座に行うことができないという事実により、SCEF は標準番号である MSISDN を介して UE と AS 通信を行う可能性を残しました。

非IPトラフィックの送信（非IPデータ配信、NIDD）

NB-IoTでは、少量のデータを送信するメカニズムの最適化の一環として、IPv4、IPv6、IPv4v6などの既存のPDNタイプに加えて、別のタイプである非IPが登場しました。 この場合、デバイス（UE）にはIPアドレスが割り当てられず、IPプロトコルを使用せずにデータが送信されます。 このような接続のトラフィックは 2 つの方法でルーティングできます。クラシック - MME -> SGW -> PGW を経由し、PtP トンネルを経由して AS に到達する（図 3）か、SCEF を使用する（図 XNUMX）。

従来の方法には、IP ヘッダーがないため送信パケットのサイズが削減されることを除いて、IP トラフィックに比べて特別な利点はありません。 SCEF を使用すると、多くの新しい可能性が開かれ、デバイスと対話する手順が大幅に簡素化されます。

SCEF 経由でデータを送信する場合、従来の IP トラフィックに比べて XNUMX つの非常に重要な利点が現れます。


外部 ID を介したデバイスへの MT トラフィックの配信

クラシック IP デバイスにメッセージを送信するには、AS はその IP アドレスを知っている必要があります。 ここで問題が発生します。通常、デバイスは登録時に「グレー」の IP アドレスを受け取るため、NAT ノードを介してインターネット上にあるアプリケーション サーバーと通信し、そこでグレーのアドレスが白に変換されます。 グレーと白の IP アドレスの組み合わせは、NAT 設定に応じて、限られた期間持続します。 TCP または UDP の場合、平均して 5 分以内です。 つまり、XNUMX 分以内にこのデバイスとのデータ交換がない場合、接続は切断され、AS とのセッションが開始されたホワイト アドレスではデバイスにアクセスできなくなります。 解決策はいくつかあります。

1. ハートビートを使用します。 接続が確立されると、デバイスは数分ごとに AS とパケットを交換する必要があるため、NAT 変換が終了するのを防ぐことができます。 しかし、ここではエネルギー効率について話すことはできません。

2. 必要に応じて毎回、AS 上のデバイスのパッケージの可用性を確認し、アップリンクにメッセージを送信します。

3. アプリケーション サーバーとデバイスが同じサブネット上にあるプライベート APN (VRF) を作成し、デバイスに静的 IP アドレスを割り当てます。 それは機能しますが、数千、数万のデバイスのフリートについて話している場合、それはほとんど不可能です。

4. 最後に、最も適切なオプション: IPv6 を使用します。IPv6 アドレスはインターネットから直接アクセスできるため、NAT は必要ありません。 ただし、この場合でも、デバイスが再登録されると、新しい IPv6 アドレスが割り当てられるため、以前のアドレスを使用してアクセスできなくなります。

したがって、デバイスの新しい IP アドレスを報告するには、デバイス識別子を含む何らかの初期化パケットをサーバーに送信する必要があります。 次に、AS からの確認パケットを待ちます。これもエネルギー効率に影響します。

これらの方法は、2G/3G/LTE デバイスに適しています。デバイスには自律性に対する厳密な要件がなく、その結果、通信時間やトラフィックに制限がありません。 これらの方法はエネルギー消費が高いため、NB-IoT には適していません。

SCEF はこの問題を解決します。AS の唯一のデバイス識別子は外部 ID であるため、AS は特定の外部 ID のデータ パケットを SCEF に送信するだけで済み、残りは SCEF が処理します。 デバイスが PSM または eDRX 省電力モードの場合、データはバッファリングされ、デバイスが使用可能になったときに配信されます。 デバイスがトラフィックに利用可能な場合、データはすぐに配信されます。 経営陣も同様です。

AS はいつでも、バッファリングされたメッセージを UE に呼び戻すか、新しいメッセージに置き換えることができます。

バッファリング メカニズムは、MO データを UE から AS に送信するときにも使用できます。 AS サーバーでメンテナンス作業が進行中の場合など、SCEF がデータを AS にすぐに配信できなかった場合、これらのパケットはバッファされ、AS が利用可能になるとすぐに配信されることが保証されます。

上で述べたように、AS の特定のサービスおよび UE (NIDD はサービスです) へのアクセスは、SCEF 側のルールとポリシーによって規制されており、これにより、複数の AS による XNUMX つの UE からのデータの同時使用という独自の可能性が可能になります。 それらの。 複数の AS が XNUMX つの UE に加入している場合、SCEF は UE からデータを受信した後、加入しているすべての AS にデータを送信します。 これは、特殊なデバイスのフリートの作成者が複数のクライアント間でデータを共有する場合に適しています。 たとえば、NB-IoT 上で動作する気象観測所のネットワークを作成すると、気象観測所からのデータを多くのサービスに同時に販売できます。

保証されたメッセージ配信メカニズム

Reliable Data Service は、TCP のハンドシェイクなど、プロトコル レベルで特殊なアルゴリズムを使用せずに、MO および MT メッセージの配信を保証するメカニズムです。 これは、UE と SCEF の間で交換されるときに、メッセージのサービス部分に特別なフラグを含めることによって機能します。 トラフィックを送信するときにこのメカニズムをアクティブにするかどうかは AS によって決定されます。

このメカニズムがアクティブ化されている場合、UE は、MO トラフィックの保証された配信を必要とするときに、パケットのオーバーヘッド部分に特別なフラグを含めます。 このようなパケットを受信すると、SCEF は UE に確認応答で応答します。 UE が確認パケットを受信しない場合、SCEF へのパケットが再送信されます。 MT トラフィックでも同じことが起こります。

デバイス監視（イベントの監視 - MONTE）

上で述べたように、SCEF 機能には、とりわけ、いわゆる UE の状態を監視するための機能が含まれています。 デバイスの監視。 そして、新しい識別子とデータ転送メカニズムが既存の手順の (非常に深刻ではあるが) 最適化である場合、MONTE は 2G/3G/LTE ネットワークでは利用できない完全に新しい機能です。 MONTE を使用すると、AS は接続ステータス、通信の可用性、位置、ローミング ステータスなどのデバイス パラメータを監視できます。 それぞれについては後ほど詳しく説明します。

デバイスまたはデバイスのグループの監視イベントをアクティブにする必要がある場合、AS は対応する API MONTE コマンドを SCEF に送信することで、対応するサービスにサブスクライブします。これには、外部 ID または外部グループ ID、AS 識別子、監視などのパラメータが含まれます。 AS が受信を希望するレポートのタイプ、数。 AS がリクエストの実行を許可されている場合、SCEF はタイプに応じてイベントを HSS または MME にプロビジョニングします (図 4)。 イベントが発生すると、MME または HSS は SCEF へのレポートを生成し、SCEF はそれを AS に送信します。

「地理的領域内に存在する UE の数」を除くすべてのイベントのプロビジョニングは、HSS を通じて行われます。 XNUMX つのイベント「IMSI-IMEI アソシエーションの変更」と「ローミング ステータス」は HSS で直接追跡され、残りは MME 上の HSS によってプロビジョニングされます。
イベントは XNUMX 回限りの場合も定期的な場合もあり、そのタイプによって決まります。

イベントに関するレポートの送信 (レポート) は、イベントを追跡するノードによって SCEF に直接送信されます (図 5)。

重要なポイント： モニタリング イベントは、SCEF 経由で接続された非 IP デバイスと、MME-SGW-PGW 経由の従来の方法でデータを送信する IP デバイスの両方に適用できます。

各監視イベントを詳しく見てみましょう。

接続の喪失 — UE がデータ トラフィックまたはシグナリングのいずれにも利用できなくなったことを AS に通知します。 このイベントは、UE の「モバイル到達可能性タイマー」が MME で期限切れになると発生します。 このタイプのモニタリングの要求では、AS はその「最大検出時間」値を示すことができます。この時間中に UE がアクティビティを示さない場合、AS は UE が利用できないことを通知され、その理由が示されます。 このイベントは、何らかの理由で UE がネットワークによって強制的に削除された場合にも発生します。

* デバイスがまだ利用可能であることをネットワークに知らせるため、更新手順であるトラッキング エリア アップデート (TAU) が定期的に開始されます。 この手順の頻度は、タイマー T3412 または (PSM の場​​合は T3412_extended) を使用してネットワークによって設定され、その値はアタッチ手順または次の TAU 中にデバイスに送信されます。 モバイル到達可能性タイマーは通常、T3412 よりも数分長くなります。 「モバイル到達可能性タイマー」の期限が切れる前に UE が TAU を作成しなかった場合、ネットワークはその UE が到達不能であるとみなします。

UEの到達可能性 – UE が DL トラフィックまたは SMS にいつ利用可能になるかを示します。 これは、UE がページング可能になったとき（eDRX モードの UE の場合）、または UE が ECM-CONNECTED モード（PSM または eDRX モードの UE の場合）に入ったときに発生します。 TAU を作成するか、アップリンク パケットを送信します。

ロケーションレポート – このタイプのモニタリング イベントにより、AS は UE の位置をクエリできます。 現在の位置 (Current Location) または最後の既知の位置 (デバイスが最後に TAU を作成したセル ID またはトラフィックを送信したセル ID によって決定される) を要求できます。これは、PSM または eDRX 省電力モードのデバイスに関連します。 「現在の位置」の場合、AS は繰り返しの応答を要求でき、デバイスの位置が変わるたびに MME が AS に通知します。

IMSI-IMEI関連付けの変更 – このイベントがアクティブになると、SCEF は IMSI (SIM カード識別子) と IMEI (デバイス識別子) の組み合わせの変更の監視を開始します。 イベントが発生すると、AS に通知します。 予定された交換作業中に外部 ID をデバイスに自動的に再バインドするために使用したり、デバイスの盗難に対する識別子として使用したりできます。

ローミングステータス – このタイプのモニタリングは、UE がホーム ネットワーク内にあるか、ローミング パートナーのネットワーク内にあるかを判断するために AS によって使用されます。 オプションで、デバイスが登録されているオペレータの PLMN (Public Land Mobile Network) を送信できます。

通信障害 — このタイプのモニタリングは、無線アクセス ネットワーク (S1-AP プロトコル) から受信した接続損失の理由 (解放原因コード) に基づいて、デバイスとの通信の失敗を AS に通知します。 このイベントは、通信が失敗した理由を特定するのに役立ちます。たとえば、eNodeb が過負荷になっている場合 (無線リソースが利用できない場合)、またはデバイス自体の障害 (UE による無線接続が失われた場合) など、ネットワーク上の問題が原因です。

DDN 障害後の可用性 – このイベントは、通信障害後にデバイスが使用可能になったことを AS に通知します。 デバイスにデータを転送する必要があるが、UE がネットワークからの通知 (ページング) に応答せず、データが配信されなかったため、前回の試行が成功しなかった場合に使用できます。 このタイプのモニタリングが UE に対して要求されている場合、デバイスが着信通信を行うか、TAU を作成するか、アップリンクにデータを送信するとすぐに、デバイスが利用可能になったことが AS に通知されます。 DDN (ダウンリンク データ通知) 手順は MME と S/P-GW の間で機能するため、このタイプの監視は IP デバイスでのみ利用できます。

PDN 接続ステータス – デバイスのステータスが変化したとき (PDN 接続ステータス)、接続 (PDN アクティブ化) または切断 (PDN 削除) を AS に通知します。 これは、AS が UE との通信を開始するために使用したり、逆に、通信がもはや不可能であることを理解するために使用したりできます。 このタイプの監視は、IP デバイスと非 IP デバイスで利用できます。

地理的エリア内に存在する UE の数 – このタイプのモニタリングは、特定の地理的エリア内の UE の数を判断するために AS によって使用されます。

デバイスのトリガー)

2G/3G ネットワークでは、ネットワークでの登録手順は 3 段階でした。まず、デバイスが SGSN に登録され（接続手順）、次に必要に応じて PDP コンテキストがアクティブ化され、パケット ゲートウェイ（GGSN）との接続が行われます。データを送信するため。 2G ネットワークでは、これら 3 つの手順が連続して発生しました。 デバイスはデータを転送する必要がある瞬間を待たず、接続手順が完了した直後に PDP をアクティブ化しました。 LTE では、これら XNUMX つの手順が XNUMX つに結合されます。つまり、アタッチ時に、デバイスは eNodeB を介して MME-SGW-PGW への PDN 接続 (XNUMXG/XNUMXG の PDP に類似) のアクティブ化を直ちに要求します。

NB-IoT では接続方式を「attach without PDN」、つまり UE が PDN 接続を確立せずにアタッチすることを定義しています。 この場合、トラフィックの送信はできず、SMS の送受信のみが可能です。 このようなデバイスにコマンドを送信して PDN をアクティブにし、AS に接続するために、「デバイス トリガー」機能が開発されました。

AS からそのような UE に接続するコマンドを受信すると、SCEF は SMS センターを通じてデバイスへの制御 SMS の送信を開始します。 SMS を受信すると、デバイスは PDN をアクティブ化し、AS に接続してさらなる指示を受信したり、データを転送したりします。

SCEF ではデバイスのサブスクリプションが期限切れになる場合があります。 はい、サブスクリプションには独自の有効期間があり、オペレーターによって設定されるか、AS との合意によって決まります。 有効期限が切れると、PDN は MME 上で非アクティブ化され、デバイスは AS で使用できなくなります。 この場合、「デバイストリガー」機能も役に立ちます。 AS から新しいデータを受信すると、SCEF はデバイスの接続ステータスを検出し、SMS チャネル経由でデータを配信します。

まとめ

もちろん、SCEF の機能は上記のサービスに限定されるものではなく、常に進化し拡張されています。 現在、十数のサービスがすでに SCEF 用に標準化されています。 ここでは、開発者から求められている主な機能についてのみ触れましたが、残りについては今後の記事で説明します。

すぐに疑問が生じます。予備テストと考えられるケースのデバッグのために、この「奇跡」ノードへのテスト アクセスを取得するにはどうすればよいでしょうか。 すべてがとてもシンプルです。 開発者は誰でもリクエストを送信できます [メール保護]、接続の目的、考えられるケースの説明、通信のための連絡先情報を示すだけで十分です。

我々は再び会うまで！

著者：

• コンバージェント ソリューションおよびマルチメディア サービス部門の上級専門家、セルゲイ ノビコフ サノフ,
• コンバージェント ソリューションおよびマルチメディア サービス部門の専門家 Alexey Lapshin アスラプシュ

出所： habr.com