W artykule "„, mówiąc o architekturze rdzenia pakietowego sieci NB-IoT, wspomnieliśmy o pojawieniu się nowego węzła SCEF. W trzeciej części wyjaśniamy, co to jest i dlaczego jest potrzebne?
Tworząc usługę M2M, twórcy aplikacji stają przed następującymi pytaniami:
- jak identyfikować urządzenia;
- jakiego algorytmu weryfikacji i uwierzytelniania użyć;
- jaki protokół transportowy wybrać do interakcji z urządzeniami;
- jak niezawodnie dostarczać dane do urządzeń;
- jak zorganizować i ustalić zasady wymiany z nimi danych;
- jak monitorować i pozyskiwać informacje o swoim stanie online;
- jak jednocześnie dostarczać dane do grupy swoich urządzeń;
- jak jednocześnie przesyłać dane z jednego urządzenia do kilku klientów;
- jak uzyskać ujednolicony dostęp do dodatkowych usług operatora umożliwiających zarządzanie urządzeniem.
Aby je rozwiązać, konieczne jest stworzenie własnych, „ciężkich” technicznie rozwiązań, co prowadzi do wzrostu kosztów pracy i czasu wprowadzenia usług na rynek. I tu z pomocą przychodzi nowy węzeł SCEF.
Zgodnie z definicją 3GPP, SCEF (funkcja ekspozycji możliwości usług) to zupełnie nowy komponent architektury 3GPP, którego funkcją jest bezpieczne udostępnianie usług i możliwości zapewnianych przez interfejsy sieciowe 3GPP za pośrednictwem interfejsów API.
Krótko mówiąc, SCEF jest pośrednikiem pomiędzy siecią a serwerem aplikacji (AS), pojedynczym oknem dostępu do usług operatora umożliwiającym zarządzanie Twoim urządzeniem M2M w sieci NB-IoT poprzez intuicyjny, ujednolicony interfejs API.
SCEF ukrywa złożoność sieci operatora, umożliwiając twórcom aplikacji abstrahowanie od skomplikowanych, specyficznych dla urządzenia mechanizmów interakcji z urządzeniami.
Przekształcając protokoły sieciowe w znane API twórcom aplikacji, SCEF API ułatwia tworzenie nowych usług i skraca czas ich wprowadzenia na rynek. W nowym węźle znajdują się także funkcje identyfikacji/uwierzytelniania urządzeń mobilnych, określenie zasad wymiany danych pomiędzy urządzeniem a systemem AS, eliminacja konieczności implementowania tych funkcji przez twórców aplikacji po ich stronie, przenosząc te funkcje na barki operatora.
SCEF obejmuje interfejsy niezbędne do uwierzytelniania i autoryzacji serwerów aplikacji, utrzymania mobilności UE, przesyłania danych i wyzwalania urządzeń, dostępu do dodatkowych usług i możliwości sieci operatora.
W stronę AS dostępny jest pojedynczy interfejs T8, API (HTTP/JSON) standaryzowany przez 3GPP. Wszystkie interfejsy, z wyjątkiem T8, działają w oparciu o protokół DIAMETER (rys. 1).
T6a – interfejs pomiędzy SCEF i MME. Wykorzystywany do procedur zarządzania mobilnością/sesją, transmisji danych innych niż IP, zapewniania zdarzeń monitorowania i otrzymywania raportów na ich temat.
S6t – interfejs pomiędzy SCEF i HSS. Wymagane do uwierzytelniania subskrybentów, autoryzacji serwerów aplikacji, uzyskiwania kombinacji zewnętrznego identyfikatora i IMSI/MSISDN, udostępniania zdarzeń monitorowania i otrzymywania raportów na ich temat.
S6m/T4 – interfejsy od SCEF do HSS i SMS-C (3GPP definiuje węzeł MTC-IWF, który służy do wyzwalania urządzeń i transmisji SMS w sieciach NB-IoT. Jednak we wszystkich wdrożeniach funkcjonalność tego węzła jest zintegrowana z SCEF, więc dla uproszczenia obwodu nie będziemy go rozważać osobno). Służy do uzyskiwania informacji o routingu w celu wysyłania wiadomości SMS i interakcji z centrum SMS.
T8 – interfejs API do interakcji SCEF z serwerami aplikacji. Przez ten interfejs przesyłane są zarówno polecenia sterujące, jak i ruch.
*w rzeczywistości interfejsów jest więcej, tutaj wymieniono tylko te najbardziej podstawowe. Pełną listę podano w 3GPP 23.682 (4.3.2 Lista punktów odniesienia).
Poniżej znajdują się najważniejsze funkcje i usługi SCEF:
- powiązanie identyfikatora karty SIM (IMSI) z identyfikatorem zewnętrznym;
- transmisja ruchu innego niż IP (Non-IP Data Delivery, NIDD);
- operacje grupowe przy użyciu zewnętrznego identyfikatora grupy;
- obsługa trybu transmisji danych z potwierdzeniem;
- buforowanie danych MO (Mobile Originated) i MT (Mobile Terminated);
- uwierzytelnianie i autoryzacja urządzeń i serwerów aplikacji;
- jednoczesne wykorzystanie danych z jednego UE przez kilka AS;
- obsługa specjalnych funkcji monitorowania stanu UE (MONTE – Monitoring Events);
- wyzwalanie urządzenia;
- zapewnianie roamingu danych bez protokołu IP.
Podstawowa zasada współdziałania AS i SCEF opiera się na tzw. schemacie. subskrypcje. Jeśli konieczne jest uzyskanie dostępu do dowolnej usługi SCEF dla konkretnego UE, serwer aplikacji musi utworzyć subskrypcję, wysyłając polecenie do konkretnego API żądanej usługi i otrzymać w odpowiedzi unikalny identyfikator. Po czym wszelkie dalsze działania i komunikacja z UE w ramach tej usługi będą odbywać się przy użyciu tego identyfikatora.
Identyfikator zewnętrzny: Uniwersalny identyfikator urządzenia
Jedną z najważniejszych zmian w schemacie interakcji AS z urządzeniami podczas pracy poprzez SCEF jest pojawienie się uniwersalnego identyfikatora. Teraz zamiast numeru telefonu (MSISDN) czy adresu IP, jak miało to miejsce w klasycznej sieci 2G/3G/LTE, identyfikatorem urządzenia dla serwera aplikacji staje się „identyfikator zewnętrzny”. Jest zdefiniowany przez standard w formacie znanym twórcom aplikacji „ @ "
Programiści nie muszą już wdrażać algorytmów uwierzytelniania urządzeń, sieć całkowicie przejmuje tę funkcję. Zewnętrzny identyfikator jest powiązany z IMSI, a programista może być pewien, że uzyskując dostęp do określonego zewnętrznego identyfikatora, wchodzi on w interakcję z konkretną kartą SIM. Korzystając z chipa SIM, zyskujesz zupełnie wyjątkową sytuację, gdy zewnętrzny identyfikator jednoznacznie identyfikuje konkretne urządzenie!
Co więcej, do jednego IMSI można powiązać kilka zewnętrznych identyfikatorów – jeszcze ciekawsza sytuacja powstaje, gdy zewnętrzny identyfikator jednoznacznie identyfikuje konkretną aplikację odpowiedzialną za konkretną usługę na konkretnym urządzeniu.
Pojawia się również identyfikator grupy - zewnętrzny identyfikator grupy, który zawiera zestaw indywidualnych identyfikatorów zewnętrznych. Teraz jednym żądaniem do SCEF AS może inicjować operacje grupowe - wysyłanie danych lub poleceń sterujących do wielu urządzeń połączonych w jedną grupę logiczną.
Z uwagi na fakt, że dla twórców AS przejście na nowy identyfikator urządzenia nie może być natychmiastowe, SCEF pozostawił możliwość komunikacji AS z UE poprzez standardowy numer - MSISDN.
Transmisja ruchu innego niż IP (Dostawa danych non-IP, NIDD)
W NB-IoT w ramach optymalizacji mechanizmów przesyłania małych ilości danych, oprócz istniejących już typów PDN, takich jak IPv4, IPv6 i IPv4v6, pojawił się kolejny typ – non-IP. W takim przypadku urządzeniu (UE) nie jest przypisywany adres IP, a dane przesyłane są bez użycia protokołu IP. Ruch dla takich połączeń może być prowadzony w dwojaki sposób: klasyczny – MME -> SGW -> PGW i dalej tunelem PtP do AS (rys. 2) lub z wykorzystaniem SCEF (rys. 3).
Klasyczna metoda nie oferuje żadnych specjalnych korzyści w stosunku do ruchu IP, z wyjątkiem zmniejszenia rozmiaru przesyłanych pakietów ze względu na brak nagłówków IP. Zastosowanie SCEF otwiera szereg nowych możliwości i znacznie upraszcza procedury interakcji z urządzeniami.
Podczas przesyłania danych poprzez SCEF w porównaniu z klasycznym ruchem IP pojawiają się dwie bardzo ważne zalety:
Dostarczanie ruchu MT do urządzenia poprzez zewnętrzny identyfikator
Aby wysłać wiadomość do klasycznego urządzenia IP, AS musi znać jego adres IP. Tutaj pojawia się problem: ponieważ urządzenie zwykle po rejestracji otrzymuje „szary” adres IP, komunikuje się z serwerem aplikacji, który znajduje się w Internecie, poprzez węzeł NAT, gdzie szary adres jest tłumaczony na biały. Kombinacja szarego i białego adresu IP trwa przez ograniczony czas, w zależności od ustawień NAT. Średnio dla protokołu TCP lub UDP - nie więcej niż pięć minut. Oznacza to, że jeśli w ciągu 5 minut nie nastąpi wymiana danych z tym urządzeniem, połączenie zostanie zerwane i urządzenie nie będzie już dostępne pod białym adresem, z którego została zainicjowana sesja z AS. Istnieje kilka rozwiązań:
1. Użyj bicia serca. Po nawiązaniu połączenia urządzenie co kilka minut musi wymieniać pakiety z systemem AS, zapobiegając w ten sposób zamknięciu translacji NAT. Ale nie można tu mówić o jakiejkolwiek efektywności energetycznej.
2. Każdorazowo, jeśli zajdzie taka potrzeba, sprawdź dostępność pakietów dla urządzenia w AS – wyślij wiadomość na uplink.
3. Utwórz prywatny APN (VRF), w którym serwer aplikacji i urządzenia będą znajdować się w tej samej podsieci, i przypisz urządzeniom statyczne adresy IP. To zadziała, ale jest to prawie niemożliwe, gdy mówimy o flocie tysięcy, dziesiątek tysięcy urządzeń.
4. Na koniec najbardziej odpowiednia opcja: użyj IPv6, nie wymaga NAT, ponieważ adresy IPv6 są bezpośrednio dostępne z Internetu. Jednak nawet w tym przypadku, gdy urządzenie zostanie ponownie zarejestrowane, otrzyma nowy adres IPv6 i nie będzie już dostępne przy użyciu poprzedniego.
W związku z tym konieczne jest wysłanie do serwera pakietu inicjującego z identyfikatorem urządzenia, aby zgłosić nowy adres IP urządzenia. Następnie poczekaj na pakiet potwierdzający od AS, który wpływa również na efektywność energetyczną.
Metody te sprawdzają się dobrze w przypadku urządzeń 2G/3G/LTE, gdzie urządzenie nie ma rygorystycznych wymagań dotyczących autonomii, a co za tym idzie, nie ma ograniczeń dotyczących czasu antenowego i ruchu. Metody te nie nadają się do NB-IoT ze względu na duże zużycie energii.
SCEF rozwiązuje ten problem: ponieważ jedynym identyfikatorem urządzenia systemu AS jest identyfikator zewnętrzny, system AS musi jedynie wysłać pakiet danych do SCEF w celu uzyskania określonego identyfikatora zewnętrznego, a SCEF zajmuje się resztą. Jeśli urządzenie znajduje się w trybie oszczędzania energii PSM lub eDRX, dane zostaną buforowane i dostarczone, gdy urządzenie stanie się dostępne. Jeśli urządzenie będzie dostępne dla ruchu, dane zostaną dostarczone natychmiast. To samo dotyczy zespołów zarządzających.
W dowolnym momencie AS może przywołać buforowany komunikat do UE lub zastąpić go nowym.
Mechanizm buforujący może być również wykorzystany podczas przesyłania danych MO z UE do AS. Jeżeli SCEF nie był w stanie natychmiast dostarczyć danych do systemu AS, na przykład jeśli na serwerach systemu AS trwają prace konserwacyjne, pakiety te zostaną buforowane i z gwarancją dostarczenia, gdy tylko system AS stanie się dostępny.
Jak wspomniano powyżej, dostęp do określonej usługi i UE dla AS (a NIDD jest usługą) regulowany jest przez zasady i polityki po stronie SCEF, co pozwala na unikalną możliwość jednoczesnego wykorzystania danych z jednego UE przez kilka AS. Te. jeżeli do jednego UE abonowało kilka AS, to po odebraniu danych od UE, SCEF prześle je do wszystkich subskrybowanych AS. Świetnie sprawdza się to w przypadkach, gdy twórca floty wyspecjalizowanych urządzeń udostępnia dane pomiędzy kilkoma klientami. Przykładowo, tworząc sieć stacji pogodowych działających na NB-IoT, możesz sprzedawać z nich dane do wielu serwisów jednocześnie.
Gwarantowany mechanizm dostarczania wiadomości
Reliable Data Service to mechanizm gwarantujący dostarczenie komunikatów MO i MT bez stosowania specjalistycznych algorytmów na poziomie protokołu, takich jak np. uzgadnianie w TCP. Działa poprzez dołączenie specjalnej flagi w części serwisowej komunikatu wymienianego między UE a SCEF. O tym, czy aktywować ten mechanizm podczas transmisji ruchu, decyduje system AS.
Jeśli mechanizm jest aktywowany, UE zawiera specjalną flagę w napowietrznej części pakietu, gdy wymaga gwarantowanego dostarczenia ruchu MO. Po otrzymaniu takiego pakietu SCEF odpowiada UE za pomocą potwierdzenia. Jeśli UE nie odbierze pakietu potwierdzenia, pakiet do SCEF zostanie wysłany ponownie. To samo dotyczy ruchu MT.
Monitoring urządzeń (monitorowanie zdarzeń - MONTE)
Jak wspomniano powyżej, funkcjonalność SCEF obejmuje między innymi funkcje monitorowania stanu UE, tzw. monitorowanie urządzenia. A jeśli nowe identyfikatory i mechanizmy przesyłania danych są optymalizacją (choć bardzo poważną) istniejących procedur, to MONTE to zupełnie nowa funkcjonalność, której nie ma w sieciach 2G/3G/LTE. MONTE umożliwia AS monitorowanie parametrów urządzenia, takich jak stan połączenia, dostępność komunikacji, lokalizacja, stan roamingu itp. O każdym z nich porozmawiamy bardziej szczegółowo nieco później.
Jeżeli konieczne jest aktywowanie dowolnego zdarzenia monitorowania dla urządzenia lub grupy urządzeń, system AS subskrybuje odpowiednią usługę, wysyłając do SCEF odpowiednią komendę API MONTE, która zawiera parametry takie jak identyfikator zewnętrzny lub identyfikator grupy zewnętrznej, identyfikator AS, monitorowanie rodzaj, ilość raportów, jakie AS chce otrzymać. Jeśli system AS jest upoważniony do wykonania żądania, SCEF, w zależności od typu, przekaże zdarzenie do HSS lub MME (rys. 4). W przypadku wystąpienia zdarzenia MME lub HSS generuje raport do SCEF, który przesyła go do systemu AS.
Udostępnianie wszystkich zdarzeń, z wyjątkiem „Liczby UE obecnych na danym obszarze geograficznym”, odbywa się za pośrednictwem HSS. Dwa zdarzenia „Zmiana stowarzyszenia IMSI-IMEI” i „Status roamingu” są śledzone bezpośrednio w HSS, reszta będzie obsługiwana przez HSS w MME.
Zdarzenia mogą mieć charakter jednorazowy lub okresowy, w zależności od ich rodzaju.
Przesłanie raportu o zdarzeniu (raportowanie) realizowane jest przez węzeł śledzący zdarzenie bezpośrednio do SCEF (rys. 5).
Ważny punkt: Zdarzenia monitoringu można zastosować zarówno do urządzeń innych niż IP podłączonych poprzez SCEF, jak i urządzeń IP przesyłających dane w sposób klasyczny poprzez MME-SGW-PGW.
Przyjrzyjmy się bliżej każdemu ze zdarzeń monitorujących:
Utrata łączności — informuje AS, że UE nie jest już dostępny ani do transmisji danych, ani do sygnalizacji. Zdarzenie ma miejsce, gdy w MME upłynie „timer dostępności mobilnej” dla UE. W żądaniu tego typu monitorowania AS może wskazać swoją wartość „Maksymalnego czasu wykrywania” – jeśli w tym czasie UE nie wykaże żadnej aktywności, AS zostanie poinformowany, że UE jest niedostępny, podając przyczynę. Zdarzenie to występuje również wtedy, gdy UE zostało z jakiegokolwiek powodu siłą usunięte z sieci.
* Aby sieć wiedziała, że urządzenie jest nadal dostępne, okresowo inicjuje procedurę aktualizacji - Aktualizacja obszaru śledzenia (TAU). Częstotliwość tej procedury jest ustalana przez sieć za pomocą timera T3412 lub (T3412_extended w przypadku PSM), którego wartość jest przesyłana do urządzenia podczas procedury Dołącz lub następnego TAU. Zegar dostępności mobilnej jest zwykle o kilka minut dłuższy niż T3412. Jeżeli UE nie dokonało TAU przed upływem „Timera osiągalności mobilnej”, sieć uważa, że jest on już nieosiągalny.
Dostępność UE – Wskazuje, kiedy UE stanie się dostępny dla ruchu DL lub SMS. Dzieje się tak, gdy UE staje się dostępny do stronicowania (dla UE w trybie eDRX) lub gdy UE przechodzi w tryb ECM-CONNECTED (dla UE w trybie PSM lub eDRX), tj. tworzy TAU lub wysyła pakiet łącza zwrotnego.
Raportowanie lokalizacji – Ten typ zdarzeń monitorowania umożliwia systemowi AS wysyłanie zapytań o lokalizację UE. Można zażądać aktualnej lokalizacji (bieżącej lokalizacji) lub ostatniej znanej lokalizacji (określanej na podstawie identyfikatora komórki, z której urządzenie wykonało TAU lub transmitowało ruch ostatnim razem), co ma znaczenie w przypadku urządzeń w trybach oszczędzania energii PSM lub eDRX. W przypadku „Aktualnej lokalizacji” system AS może żądać powtarzanych odpowiedzi, przy czym MME informuje system AS za każdym razem, gdy zmienia się lokalizacja urządzenia.
Zmiana stowarzyszenia IMSI-IMEI – Po aktywowaniu tego zdarzenia SCEF zaczyna monitorować zmiany w kombinacji IMSI (identyfikator karty SIM) i IMEI (identyfikator urządzenia). Gdy wystąpi jakieś zdarzenie, informuje AS. Może służyć do automatycznego ponownego powiązania zewnętrznego identyfikatora z urządzeniem podczas zaplanowanej wymiany lub służyć jako identyfikator w przypadku kradzieży urządzenia.
Status roamingu – ten rodzaj monitorowania jest wykorzystywany przez AS w celu ustalenia, czy UE znajduje się w sieci macierzystej, czy w sieci partnera roamingowego. Opcjonalnie możliwa jest transmisja PLMN (Public Land Mobile Network) operatora, u którego zarejestrowane jest urządzenie.
Błąd w komunikacji — Ten rodzaj monitorowania informuje AS o awariach komunikacji z urządzeniem na podstawie przyczyn utraty połączenia (kodu przyczyny zwolnienia) otrzymanych z radiowej sieci dostępowej (protokół S1-AP). To zdarzenie może pomóc w ustaleniu przyczyny niepowodzenia komunikacji - z powodu problemów w sieci, na przykład w przypadku przeciążenia eNodebu (brak zasobów radiowych) lub z powodu awarii samego urządzenia (utracono połączenie radiowe z UE).
Dostępność po awarii DDN – zdarzenie to informuje AS, że urządzenie stało się dostępne po awarii komunikacji. Można zastosować, gdy istnieje potrzeba przesłania danych do urządzenia, ale poprzednia próba nie powiodła się, ponieważ UE nie odpowiedziało na powiadomienie z sieci (stronicowanie) i dane nie zostały dostarczone. Jeżeli dla UE zażądano tego rodzaju monitorowania, wówczas gdy tylko urządzenie nawiąże komunikację przychodzącą, wykona TAU lub wyśle dane do łącza zwrotnego, system AS zostanie poinformowany, że urządzenie stało się dostępne. Ponieważ procedura DDN (powiadomienie o danych w łączu w dół) działa pomiędzy MME i S/P-GW, ten typ monitorowania jest dostępny tylko dla urządzeń IP.
Stan połączenia PDN – informuje AS o zmianie stanu urządzenia (status łączności PDN) - połączeniu (aktywacja PDN) lub rozłączeniu (usunięcie PDN). Może to zostać wykorzystane przez system AS do zainicjowania komunikacji z UE lub odwrotnie, aby zrozumieć, że komunikacja nie jest już możliwa. Ten typ monitorowania jest dostępny dla urządzeń IP i innych.
Liczba UE obecnych na danym obszarze geograficznym – Ten rodzaj monitorowania jest stosowany przez system operacyjny w celu określenia liczby UE na określonym obszarze geograficznym.
Wyzwalanie urządzenia)
W sieciach 2G/3G procedura rejestracji w sieci była dwuetapowa: najpierw urządzenie rejestrowało się w SGSN (procedura dołączania), następnie w razie potrzeby uruchamiało kontekst PDP – połączenie z bramką pakietową (GGSN) do przesyłania danych. W sieciach 3G te dwie procedury występowały sekwencyjnie, tj. urządzenie nie czekało na moment, w którym należało przesłać dane, ale aktywowało PDP natychmiast po zakończeniu procedury dołączania. W LTE te dwie procedury zostały połączone w jedną, czyli po podłączeniu urządzenie od razu żądało aktywacji połączenia PDN (analogicznie do PDP w 2G/3G) poprzez eNodeB do MME-SGW-PGW.
NB-IoT definiuje metodę połączenia jako „dołącz bez PDN”, co oznacza, że UE podłącza się bez ustanawiania połączenia PDN. W takim przypadku nie można przesyłać ruchu i można jedynie odbierać lub wysyłać wiadomości SMS. W celu wysłania do takiego urządzenia polecenia aktywacji PDN i połączenia z AS opracowano funkcjonalność „Wyzwalanie urządzenia”.
Po otrzymaniu polecenia podłączenia takiego UE od AS, SCEF inicjuje wysyłanie sterującego SMS-a do urządzenia za pośrednictwem centrum SMS. Po odebraniu wiadomości SMS urządzenie aktywuje PDN i łączy się z AS w celu otrzymania dalszych instrukcji lub przesłania danych.
Może się zdarzyć, że subskrypcja Twojego urządzenia w SCEF wygaśnie. Tak, abonament ma swój własny czas życia, ustalany przez operatora lub uzgodniony z AS. Po wygaśnięciu nazwa PDN zostanie dezaktywowana w MME, a urządzenie stanie się niedostępne dla systemu AS. W tym przypadku pomocna będzie także funkcja „Wyzwalanie urządzenia”. Po otrzymaniu nowych danych od AS, SCEF sprawdzi stan połączenia urządzenia i przekaże dane kanałem SMS.
wniosek
Funkcjonalność SCEF nie ogranicza się oczywiście do opisanych powyżej usług i stale się rozwija i poszerza. Obecnie dla SCEF ujednolicono już kilkanaście usług. Teraz poruszyliśmy tylko główne funkcje, na które jest zapotrzebowanie programistów, o reszcie 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 przetestowania i debugowania możliwych przypadków? Wszystko jest bardzo proste. Każdy programista może przesłać żądanie do [email chroniony], w którym wystarczy wskazać cel połączenia, opis ewentualnej sprawy oraz dane kontaktowe w celu komunikacji.
Do następnego razu!
Autorzy:
- starszy ekspert w dziale rozwiązań konwergentnych i usług multimedialnych Siergiej Nowikow ,
- ekspert działu rozwiązań konwergentnych i usług multimedialnych Alexey Lapshin
Źródło: www.habr.com