NB-IoT: jak to działa? Część 3: SCEF – jedno okno dostępu do usług operatora

W artykule „NB-IoT: jak to działa? Część 2”, opowiadając o architekturze pakietowego jądra sieci NB-IoT, wspomnieliśmy o pojawieniu się nowego węzła SCEF. Wyjaśniamy w trzeciej części, czym to jest i po co jest potrzebne?

Tworząc usługę M2M, deweloperzy aplikacji stają przed następującymi pytaniami:

• jak zidentyfikować urządzenia;
• jaki algorytm użyć do weryfikacji i potwierdzenia tożsamości;
• jaki protokół transportowy wybrać do komunikacji z urządzeniami;
• jak zagwarantować dostarczenie danych do urządzeń;
• jak zorganizować i ustalić zasady wymiany danych z nimi;
• jak kontrolować i w czasie rzeczywistym uzyskać informacje o ich stanie;
• jak jednocześnie dostarczyć dane do grupy swoich urządzeń;
• jak jednocześnie wysłać dane z jednego urządzenia do kilku klientów;
• jak uzyskać zunifikowany dostęp do dodatkowych usług operatora w celu zarządzania swoim urządzeniem.

Aby je rozwiązać, trzeba tworzyć własnościowe technicznie „ciężkie” rozwiązania, co prowadzi do zwiększenia nakładu pracy i czasu wprowadzenia usług na rynek. Tutaj z pomocą przychodzi nowy węzeł SCEF.

Zgodnie z definicją 3GPP, SCEF (funkcja eksponowania zdolności usługowych) to zupełnie nowy komponent architektury 3GPP, którego funkcją jest bezpieczne eksponowanie usług i możliwości oferowanych przez interfejsy sieciowe 3GPP za pośrednictwem API.

Mówiąc prościej, SCEF to pośrednik między siecią a serwerem aplikacji (application server — AS), stanowiący jednolite okno dostępu do usług operatora w celu zarządzania swoim urządzeniem M2M w sieci NB-IoT za pośrednictwem intuicyjnego, ustandaryzowanego interfejsu API.

SCEF ukrywa złożoność sieci operatora, pozwalając deweloperom aplikacji abstrahować od skomplikowanych, specyficznych mechanizmów interakcji z urządzeniami.

Dzięki przekształceniu protokołów sieciowych w znajomy dla deweloperów aplikacji interfejs API, SCEF ułatwia tworzenie nowych usług i skraca czas wprowadzenia na rynek. Nowy węzeł zawiera również funkcje identyfikacji/autoryzacji urządzeń mobilnych oraz określania zasad wymiany danych między urządzeniem a AS, znosząc konieczność implementacji tych funkcji po stronie deweloperów aplikacji, przenosząc te zadania na operatora.

SCEF skupia interfejsy niezbędne do uwierzytelniania i autoryzacji serwerów aplikacji, utrzymania mobilności UE, przesyłania danych oraz wyzwalania urządzeń, jak również dostępu do dodatkowych usług i możliwości sieci operatora.

W kierunku AS idzie jeden jedyny interfejs T8, interfejs API (HTTP/JSON), standaryzowany przez 3GPP. Wszystkie interfejsy, z wyjątkiem T8, działają na bazie protokołu DIAMETER (rys. 1).

T6a to interfejs między SCEF a MME. Służy do procedur zarządzania mobilnością/sesjami, przesyłania danych non-IP, provisioningu zdarzeń monitorowania oraz otrzymywania raportów dotyczących tych zdarzeń.

S6t to interfejs między SCEF a HSS. Niezbędny do uwierzytelniania abonenta, autoryzacji serwerów aplikacji, uzyskania powiązania external ID oraz IMSI/MSISDN, provisioningu zdarzeń monitorowania oraz otrzymywania raportów dotyczących tych zdarzeń.

S6m/T4 to interfejsy od SCEF do HSS i SMS-C (w 3GPP określony jako węzeł MTC-IWF, który jest wykorzystywany do wyzwalania urządzeń oraz przesyłania SMS w sieciach NB-IoT. Jednak we wszystkich realizacjach funkcjonalność tego węzła jest zintegrowana z SCEF, więc dla uproszczenia schematu nie będziemy go rozpatrywać osobno). Służą do uzyskania informacji o trasie dla wysyłania SMS oraz interakcji z centrum SMS.

T8 to interfejs API interakcji SCEF z serwerami aplikacji. Przez ten interfejs przesyłane są zarówno komendy sterujące, jak i ruch.

*w rzeczywistości interfejsów jest więcej, tutaj wymienione są tylko najważniejsze. Pełna lista znajduje się w 3GPP 23.682 (4.3.2 Lista punktów odniesienia).

Poniżej przedstawione są kluczowe funkcje i usługi SCEF:

• przypisanie identyfikatora karty SIM (IMSI) do external ID;
• przesyłanie ruchu non-IP (Non-IP Data Delivery, NIDD);
• operacje grupowe z wykorzystaniem external group ID;
• wsparcie dla trybu przesyłania danych z potwierdzeniem;
• buforowanie danych MO (Mobile Originated) i MT (Mobile Terminated);
• uwierzytelnianie i autoryzacja urządzeń oraz serwerów aplikacji;
• jednoczesne wykorzystanie danych jednego UE przez wiele AS;
• wsparcie dla specjalnych funkcji kontroli stanu UE (MONTE – Monitoring Events);
• wyzwalanie urządzeń;
• zapewnienie roamingu danych non-IP.

Podstawową zasadą interakcji między AS a SCEF jest model tzw. subskrypcji. W przypadku potrzeby uzyskania dostępu do konkretnej usługi SCEF dla danego UE, serwer aplikacji musi stworzyć subskrypcję, wysyłając polecenie na konkretny interfejs API żądanej usługi i w odpowiedzi otrzymać unikalny identyfikator. Po tym wszystkie dalsze działania i komunikacje z UE w ramach tej usługi będą odbywać się przy użyciu tego identyfikatora.

External ID: uniwersalny identyfikator urządzenia

Jedną z najważniejszych zmian w schemacie interakcji AS z urządzeniami podczas pracy przez SCEF jest pojawienie się uniwersalnego identyfikatora. Teraz zamiast numeru telefonu (MSISDN) czy adresu IP, jak to miało miejsce w klasycznej sieci 2G/3G/LTE, identyfikatorem urządzenia dla serwera aplikacji staje się „external ID”. Jest on zdefiniowany przez standard w znanym dla programistów formacie „@”.

Programiści nie muszą już wdrażać algorytmów uwierzytelniania urządzeń, sieć w pełni przejmuje tę funkcję. External ID jest powiązane z IMSI, a programista może być pewien, że wzywając konkretny external ID, wchodzi w interakcję z konkretną kartą SIM. Przy użyciu chipu SIM uzyskuje się sytuację, w której external ID jednoznacznie identyfikuje konkretne urządzenie!

Co więcej, do jednego IMSI można powiązać kilka external ID — pojawia się jeszcze bardziej interesująca sytuacja, gdy external ID jednoznacznie identyfikuje konkretne aplikacje odpowiedzialne za określoną usługę na konkretnym urządzeniu.

Pojawia się również identyfikator grupowy — external group ID, który obejmuje zestaw pojedynczych external ID. Teraz jednym żądaniem do SCEF AS można inicjować operacje grupowe — wysyłanie danych lub poleceń do wielu urządzeń połączonych w jedną logiczną grupę.

Ze względu na to, że dla programistów AS przejście na nowy identyfikator urządzenia nie może być natychmiastowe, SCEF pozostawił możliwość komunikacji AS z UE przez standardowy numer – MSISDN.

Przesyłanie ruchu non-IP (Non-IP Data Delivery, NIDD)

W NB-IoT, w ramach optymalizacji mechanizmów przesyłania małych ilości danych, obok istniejących typów PDN, takich jak IPv4, IPv6 i IPv4v6, pojawił się kolejny typ — non-IP. W tym przypadku urządzenie (UE) nie otrzymuje adresu IP, a dane są przesyłane bez użycia protokołu IP. Ruch dla takich połączeń może być routowany na dwa sposoby: klasyczny — MME -> SGW -> PGW, a następnie przez tunel PtP do AS (rys. 2) lub z wykorzystaniem SCEF (rys. 3).

Klasyczny sposób nie niesie ze sobą szczególnych zalet w porównaniu do ruchu IP, z wyjątkiem zmniejszenia rozmiaru przesyłanych pakietów dzięki braku nagłówków IP. Zastosowanie SCEF otwiera jednak szereg nowych możliwości i znacznie upraszcza procedury interakcji z urządzeniami.

Przy przesyłaniu danych przez SCEF pojawiają się dwie bardzo ważne zalety w porównaniu do klasycznego ruchu IP:

Dostarczenie ruchu MT do urządzenia za pomocą external ID

Aby wysłać wiadomość do klasycznego urządzenia IP — AS musi znać jego adres IP. Tutaj pojawia się problem: ponieważ urządzenie podczas rejestracji zwykle otrzymuje «szary» adres IP, komunikuje się z serwerem aplikacji, który znajduje się w Internecie, przez węzeł NAT, gdzie następuje translacja szarego adresu na biały. Związek szarego i białego adresu IP utrzymuje się przez ograniczony czas, w zależności od ustawień NAT. Średnio dla TCP lub UDP — nie dłużej niż pięć minut. Oznacza to, że jeśli w ciągu 5 minut nie było wymiany danych z tym urządzeniem, związek się rozpada i urządzenie przestaje być dostępne pod tym białym adresem, z którym została zainicjowana sesja z AS. Istnieje kilka rozwiązań:

1. Użyć heartbeat. Po jednorazowym nawiązaniu połączenia urządzenie powinno wymieniać z AS pakiety co kilka minut, aby nie dopuścić do zamknięcia translacji na NAT. Ale tutaj nie ma mowy o żadnej efektywności energetycznej.

2. Za każdym razem, gdy to konieczne, sprawdzać dostępność pakietów dla urządzenia na AS — wysyłać wiadomość w uplink.

3. Stworzyć prywatny APN (VRF), w którym serwer aplikacji i urządzenia będą znajdować się w tej samej podsieci, i przypisać urządzeniom statyczne adresy IP. To będzie działać, ale prawie nie jest wykonalne, gdy mowa o parku składającym się z tysięcy, dziesiątek tysięcy urządzeń.

4. Ostatecznie, najdogodniejsza opcja: używać IPv6, ponieważ nie wymaga NAT, a adresy IPv6 są dostępne bezpośrednio z Internetu. Jednak nawet w tym przypadku, przy ponownej rejestracji urządzenia, otrzyma ono nowy adres IPv6 i nie będzie już dostępne pod poprzednim.

W związku z tym konieczne jest wysłanie jakiegoś pakietu inicjującego z identyfikatorem urządzenia do serwera, aby poinformować o nowym adresie IP urządzenia. Następnie trzeba czekać na potwierdzający pakiet od AS, co również wpływa na efektywność energetyczną.

Te metody dobrze działają dla urządzeń 2G/3G/LTE, gdzie nie stawiane są rygorystyczne wymagania dotyczące autonomiczności, co wiąże się z brakiem ograniczeń co do czasu w eterze i ruchu. Dla NB-IoT te metody nie są odpowiednie ze względu na ich dużą energochłonność.

SCEF rozwiązuje ten problem: ponieważ jedynym identyfikatorem urządzenia dla AS jest external ID, AS wystarczy wysłać pakiet danych do SCEF dla konkretnego external ID, a SCEF zajmie się wszystkim innym. W przypadku, gdy urządzenie jest w trybie oszczędzania energii PSM lub eDRX, dane będą buforowane i dostarczone, gdy urządzenie stanie się dostępne. Jeśli jednak urządzenie jest dostępne dla ruchu, dane będą dostarczone natychmiast. To samo dotyczy poleceń zarządzających.

W każdej chwili AS może anulować buforowaną wiadomość w kierunku UE lub zastąpić ją nową.

Mechanizm buforowania może być również stosowany przy przesyłaniu danych MO od UE w kierunku AS. Jeśli SCEF nie mógł dostarczyć danych do AS od razu, na przykład w przypadku prac serwisowych na serwerach AS, te pakiety będą buforowane i zapewnione dostarczenie ich, gdy AS stanie się dostępny.

Jak wspomniano powyżej, dostęp do określonej usługi i UE dla AS (a NIDD to usługa) jest regulowany zasadami i politykami po stronie SCEF, co umożliwia unikalną możliwość jednoczesnego wykorzystania danych jednego UE przez kilka AS. Tzn. jeśli kilka AS zapisało się na jedno UE, to po otrzymaniu danych z UE, SCEF rozsyła je do wszystkich zapisujących się AS. Dobrze nadaje się to do przypadków, gdy twórca parku wyspecjalizowanych urządzeń dzieli się danymi między wieloma klientami. Na przykład, tworząc sieć stacji meteorologicznych działających na NB-IoT, można sprzedawać dane z nich wielu usługom jednocześnie.

Mechanizm gwarantowanej dostawy wiadomości

Reliable Data Service — mechanizm gwarantowanej dostawy wiadomości MO i MT bez użycia specjalizowanych algorytmów na poziomie protokołu, takich jak handshake w TCP. Działa dzięki włączeniu specjalnego flagu w części służbowej wiadomości podczas wymiany między UE a SCEF. Aktywacja lub dezaktywacja tego mechanizmu podczas przesyłania danych jest decyzją AS.

Jeśli mechanizm jest aktywowany, UE w przypadku gwarantowanej dostawy ruchu MO włącza specjalny flag w części służbowej pakietu. Po odebraniu takiego pakietu SCEF odpowiada UE potwierdzeniem. Jeśli UE nie otrzymała pakietu z potwierdzeniem, pakiet w stronę SCEF zostanie ponownie wysłany. To samo dotyczy ruchu MT.

Monitorowanie urządzeń (monitoring events- MONTE)

Jak wspomniano wcześniej, funkcjonalność SCEF, oprócz innych, obejmuje funkcje kontroli stanu UE, znane jako monitorowanie urządzeń. I jeśli nowe identyfikatory i mechanizmy przesyłania danych są optymalizacjami (choć bardzo poważnymi) już istniejących procedur, to MONTE to całkowicie nowa funkcjonalność, niedostępna w sieciach 2G/3G/LTE. MONTE pozwala AS śledzić takie parametry urządzenia, jak status połączenia, dostępność do komunikacji, lokalizację, status roamingu itd. Więcej szczegółów podamy nieco później.

W razie potrzeby aktywować jakiekolwiek zdarzenie monitorowania dla urządzenia lub grupy urządzeń, AS zapisuje się na odpowiednią usługę, wysyłając do SCEF polecenie odpowiedniego API MONTE, które zawiera takie parametry jak external Id lub external group ID, identyfikator AS, typ monitorowania, liczba raportów, które AS chce otrzymać. Jeśli AS jest autoryzowany do wykonania żądania, SCEF w zależności od typu zrealizuje zdarzenie na HSS lub MME (rys. 4). Po wystąpieniu zdarzenia MME lub HSS generują raport w stronę SCEF, który wysyła go do AS.

Prowizjonowanie wszystkich zdarzeń, z wyjątkiem „Liczby UEs obecnych w obszarze geograficznym”, odbywa się przez HSS. Dwa zdarzenia „Zmiana stowarzyszenia IMSI-IMEI” i „Status roamingu” są śledzone bezpośrednio na HSS, pozostałe HSS prowizjonuje na MME.
Zdarzenia mogą być jednorazowe lub cykliczne i są uzależnione od ich typu.

Wysyłanie raportu o zdarzeniu (raportowanie) jest realizowane przez węzeł monitorujący zdarzenie bezpośrednio do SCEF (rys. 5).

Ważny punkt: zdarzenia monitorowania mogą dotyczyć zarówno urządzeń non-IP połączonych przez SCEF, jak i urządzeń IP przesyłających dane w tradycyjny sposób przez MME-SGW-PGW.

Przyjrzyjmy się bliżej każdemu z zdarzeń monitorowania:

Utrata łączności — informuje AS, że UE nie jest już dostępna ani dla ruchu danych, ani dla wymiany sygnałowej. Zdarzenie to występuje, gdy na MME wygaśnie "mobile reachability timer" dla UE. W żądaniu dotyczącego tego typu monitorowania AS może określić swoje własne wartości "Maximum Detection Time" — jeśli w trakcie tego czasu UE nie wykaże żadnej aktywności, AS zostanie poinformowany, że UE jest niedostępna, z podaniem przyczyny. Zdarzenie to występuje również, gdy UE zostaje z jakiegoś powodu wymuszenie usunięta z sieci.

* Aby sieć wiedziała, że urządzenie jest nadal dostępne, okresowo inicjuje procedurę aktualizacji — Tracking Area Update (TAU). Częstotliwość tej procedury jest ustawiana przez sieć za pomocą timera T3412 lub (T3412_extended w przypadku PSM), którego wartość jest przekazywana urządzeniu w trakcie procedury Attach lub kolejnego TAU. Timer dostępności mobilnej zwykle jest o kilka minut dłuższy niż T3412. Jeśli UE przed upływem "Mobile reachability timer" nie wykona TAU, sieć uznaje je za niedostępne.

Dostępność UE – pokazuje, kiedy UE staje się dostępna dla ruchu DL lub SMS. Dzieje się to, gdy UE staje się dostępna do stronnicowania (dla UE w trybie eDRX) lub kiedy UE przechodzi w tryb ECM-CONNECTED (dla UE w trybie PSM lub eDRX), tj. wykonuje TAU lub wysyła pakiet w górę.

Raportowanie lokalizacji – ten rodzaj zdarzeń monitorujących pozwala AS zażądać danych o lokalizacji UE. Może być żądana zarówno aktualna lokalizacja (Current Location), jak i ostatnia znana (Last Known Location, określana na podstawie cell ID, z którego urządzenie wykonało TAU lub przesyłało ruch po raz ostatni), co jest istotne dla urządzeń znajdujących się w trybach oszczędzania energii PSM lub eDRX. Dla "Current Location" AS może zażądać powtarzających się raportów, a MME będzie informować AS za każdym razem o zmianie lokalizacji urządzenia.

Zmiana powiązania IMSI-IMEI – Po aktywacji tego zdarzenia SCEF zaczyna śledzić zmiany powiązania IMSI (identyfikator karty SIM) i IMEI (identyfikator urządzenia). W przypadku wystąpienia zdarzenia informuje AS. Może być używane do automatycznego przypisania external ID do urządzenia podczas planowych prac wymiany lub służyć jako identyfikator kradzieży urządzenia.

Status roamingu – ten rodzaj monitorowania jest używany przez AS, aby określić, czy UE znajduje się w domowej sieci, czy w sieci partnera roamingowego. Opcjonalnie może być przekazany PLMN (Public Land Mobile Network) operatora, w którym urządzenie jest zarejestrowane.

Awaria komunikacji — Ten typ monitorowania informuje AS o awariach w komunikacji z urządzeniem, opierając się na przyczynach przerwania połączenia (release cause code) uzyskanych od sieci radiowej (protokół S1-AP). To zdarzenie może pomóc ustalić, dlaczego wystąpiła awaria komunikacji — z powodu problemów w sieci, na przykład przy przeciążeniu eNodeB (Radio resources not available) lub z powodu awarii samego urządzenia (Radio Connection With UE Lost).

Dostępność po awarii DDN – to zdarzenie informuje AS, że urządzenie stało się dostępne po awarii komunikacji. Może być stosowane, gdy konieczne jest przesłanie danych do urządzenia, ale poprzednia próba była nieudana, ponieważ UE nie odpowiedziała na powiadomienie od sieci (paging), więc dane nie zostały dostarczone. Jeśli ten typ monitorowania został zażądany dla UE, to gdy tylko urządzenie wykona połączenie przychodzące, przeprowadzi TAU lub wyśle dane w kierunku uplinku, AS zostanie poinformowane, że urządzenie stało się dostępne. Ponieważ procedura DDN (downlink data notification) działa między MME a S/P-GW, ten rodzaj monitorowania jest dostępny tylko dla urządzeń IP.

Status łączności PDN – informuje AS o zmianie statusu urządzenia (PDN connectivity status) — połączenia (aktywacja PDN) lub rozłączenia (usunięcie PDN). Może być używane przez AS do inicjacji komunikacji z UE lub odwrotnie, do zrozumienia, że komunikacja już nie jest możliwa. Ten typ monitorowania jest dostępny dla urządzeń IP oraz non-IP.

Liczba UE w danym obszarze geograficznym – ten typ monitorowania jest używany przez AS, aby określić liczbę UE w określonej strefie geograficznej.

Urządzenia wyzwalające (Device triggering)

W sieciach 2G/3G procedura rejestracji w sieci była dwuetapowa: najpierw urządzenie rejestrowało się w SGSN (procedura attach), a następnie, w razie potrzeby przesłania danych, aktywowało PDP context – połączenie z bramą pakietową (GGSN). W sieciach 3G te dwie procedury następowały po sobie, tzn. urządzenie nie czekało na moment, gdy trzeba przesłać dane, a aktywowało PDP od razu po zakończeniu procedury attach. W LTE te dwie procedury zostały połączone w jedną, co oznacza, że przy attach urządzenie od razu żądało aktywacji PDN connection (analogicznie do PDP w 2G/3G) przez eNodeB do MME-SGW-PGW.

W NB-IoT zdefiniowano sposób połączenia, taki jak „attach without PDN”, co oznacza, że UE dokonuje attach, nie ustanawiając połączenia PDN. W takim przypadku nie jest dostępne do przesyłania ruchu i może tylko odbierać lub wysyłać SMS. Aby przesłać na takie urządzenie polecenie aktywacji PDN i połączenia z AS, opracowano funkcjonalność „Device triggering”.

Po otrzymaniu polecenia połączenia takiego UE od AS, SCEF za pośrednictwem centrum SMS inicjuje wysłanie zarządzającej wiadomości SMS do urządzenia. Po otrzymaniu SMS urządzenie aktywuje PDN i łączy się z AS, aby otrzymać kolejne instrukcje lub przesłać dane.

Mogą wystąpić przypadki, gdy na SCEF wygaśnie subskrypcja urządzenia. Tak, subskrypcja ma swoją żywotność, ustaloną przez operatora lub uzgodnioną z AS. Po jej wygaśnięciu na MME zadeaktywowana zostanie PDN, a urządzenie stanie się niedostępne dla AS. W takim przypadku również pomoże funkcjonalność „Device triggering”. Po otrzymaniu nowych danych od AS SCEF ustali status połączenia urządzenia i przekaże dane przez kanał SMS.

Podsumowanie

Funkcjonalność SCEF, oczywiście, nie ogranicza się do opisanych powyżej usług i stale ewoluuje oraz rozszerza się. Obecnie dla SCEF już ustandaryzowano ponad dziesięć usług. Dotknęliśmy teraz tylko podstawowych i poszukiwanych przez deweloperów funkcji, o pozostałych porozmawiamy w przyszłych artykułach.

Od razu pojawia się pytanie, jak uzyskać dostęp testowy do tego „cudownego” węzła w celu wstępnego testowania i debugowania możliwych przypadków? To bardzo proste. Każdy deweloper może wysłać zapytanie na iot.info@mts.ru, w którym wystarczy podać cel połączenia, opis możliwego przypadku oraz dane kontaktowe do kontaktu.

Do zobaczenia!

Autorzy:

• starszy ekspert ds. rozwiązań konwergentnych i usług multimedialnych Siergiej Nowikow sanov,
• ekspert ds. rozwiązań konwergentnych i usług multimedialnych Aleksiej Łapszin aslapsh

Źródło: habr.com