W artykule "„, mówiąc o architekturze rdzenia pakietów sieciowych NB-IoT, wspomnieliśmy o pojawieniu się nowego węzła SCEF. W części trzeciej wyjaśniamy, czym on jest i dlaczego jest potrzebny?
Tworząc usługę M2M, twórcy aplikacji stają przed następującymi pytaniami:
- jak identyfikować urządzenia;
- jaki algorytm zastosować do weryfikacji i uwierzytelniania;
- jaki protokół transportowy wybrać do interakcji z urządzeniami;
- jak zapewnić dostarczenie danych do urządzeń;
- jak organizować i ustalać zasady wymiany danych z nimi;
- jak kontrolować i uzyskiwać informacje o swoim stanie zdrowia w Internecie;
- jak dostarczać dane do grupy urządzeń w tym samym czasie;
- jak przesyłać dane z jednego urządzenia do wielu klientów jednocześnie;
- jak uzyskać ujednolicony dostęp do dodatkowych usług operatora w celu zarządzania urządzeniem.
Aby je rozwiązać, konieczne jest tworzenie autorskich, technicznie „ciężkich” rozwiązań, co wiąże się ze wzrostem kosztów pracy i czasem wprowadzania usług na rynek. W tym miejscu z pomocą przychodzi nowy węzeł SCEF.
Zgodnie z definicją 3GPP, SCEF (service capabilities exposure function) jest zupełnie nowym komponentem architektury 3GPP, którego funkcją jest bezpieczne udostępnianie usług i możliwości udostępnianych przez interfejsy sieciowe 3GPP za pośrednictwem interfejsów API.
Mówiąc najprościej, SCEF jest pośrednikiem między siecią a serwerem aplikacji (AS), pojedynczym oknem dostępu do usług operatora umożliwiającym zarządzanie jego urządzeniem M2M w sieci NB-IoT za pośrednictwem intuicyjnego, standardowego interfejsu API.
SCEF ukrywa złożoność sieci operatora, pozwalając twórcom aplikacji na pominięcie skomplikowanych mechanizmów interakcji specyficznych dla danego urządzenia.
Przekształcając protokoły sieciowe w interfejs API znany twórcom aplikacji, SCEF ułatwia tworzenie nowych usług i skraca czas wprowadzania produktów na rynek. Nowy węzeł obejmuje również funkcje identyfikacji/uwierzytelniania urządzeń mobilnych, definiowania reguł wymiany danych pomiędzy urządzeniem a systemem autonomicznym, eliminując potrzebę wdrażania tych funkcji przez deweloperów aplikacji, przenosząc te funkcje na barki operatora.
SCEF obejmuje interfejsy niezbędne do uwierzytelniania i autoryzacji serwerów aplikacji, utrzymania mobilności UE, transmisji danych i wyzwalania urządzeń, dostępu do dodatkowych usług i możliwości sieci operatora.
Istnieje tylko jeden interfejs T8 do AS, interfejs API (HTTP/JSON) standaryzowany przez 3GPP. Wszystkie interfejsy, poza T8, działają w oparciu o protokół DIAMETER (rys. 1).
T6a – interfejs pomiędzy SCEF i MME. Używany do procedur zarządzania mobilnością/sesją, transferu danych bez protokołu IP, zapewniania zdarzeń monitorujących i otrzymywania raportów na ich temat.
S6t – interfejs pomiędzy SCEF i HSS. Wymagane do uwierzytelniania subskrybentów, autoryzacji serwerów aplikacji, uzyskiwania zewnętrznego identyfikatora i łączy IMSI/MSISDN, obsługi zdarzeń monitorujących i otrzymywania raportów na ich temat.
S6m/T4 – interfejsy z SCEF do HSS i SMS-C (3GPP definiuje węzeł MTC-IWF, który jest używany do wyzwalania urządzeń i transmisji SMS w sieciach NB-IoT. Jednak we wszystkich implementacjach funkcjonalność tego węzła jest zintegrowana ze SCEF, więc aby uprościć diagram, nie będziemy go rozważać oddzielnie). Służy do uzyskiwania informacji o routingu do wysyłania wiadomości SMS i interakcji z centrum SMS.
T8 to interfejs API umożliwiający interakcję SCEF z serwerami aplikacji. Poprzez 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łna lista znajduje się w dokumencie 3GPP 23.682 (4.3.2 Lista punktów odniesienia).
Poniżej przedstawiono najważniejsze cechy i usługi SCEF:
- powiązanie identyfikatora karty SIM (IMSI) z zewnętrznym identyfikatorem;
- przesyłanie ruchu nie-IP (Non-IP Data Delivery, NIDD);
- operacje grupowe przy użyciu zewnętrznego identyfikatora grupy;
- obsługa trybu przesyłu danych z potwierdzeniem;
- buforowanie danych MO (Mobile Originated) i MT (Mobile Terminated);
- uwierzytelnianie i autoryzacja urządzeń i serwerów aplikacji;
- jednoczesne korzystanie z danych z jednego UE przez kilka AS;
- obsługa specjalnych funkcji monitorowania statusu UE (MONTE – Monitoring Events);
- wyzwalanie urządzenia;
- Zapewnianie roamingu danych bez protokołu IP.
Podstawowa zasada interakcji między AS i SCEF opiera się na tzw. subskrypcjach. Gdy wymagany jest dostęp do usługi SCEF dla konkretnego UE, serwer aplikacji musi utworzyć subskrypcję, wysyłając polecenie do konkretnego interfejsu API żądanej usługi i otrzymując w odpowiedzi unikalny identyfikator. Następnie wszelkie dalsze działania i komunikacja z UE w ramach tej usługi będą się odbywać przy użyciu tego identyfikatora.
Identyfikator zewnętrzny: Uniwersalny identyfikator urządzenia
Jedną z najważniejszych zmian w schemacie interakcji AS z urządzeniami pracującymi poprzez SCEF jest pojawienie się uniwersalnego identyfikatora. Teraz zamiast numeru telefonu (MSISDN) lub adresu IP, jak to było w klasycznej sieci 2G/3G/LTE, identyfikatorem urządzenia dla serwera aplikacji jest „identyfikator zewnętrzny”. Jest on zdefiniowany w standardzie w formacie znanym twórcom aplikacji” @ ".
Programiści nie muszą już wdrażać algorytmów uwierzytelniania urządzeń; Sieć przejmuje tę funkcję całkowicie. Zewnętrzny identyfikator jest powiązany z systemem IMSI, dzięki czemu deweloper ma pewność, że uzyskując dostęp do konkretnego zewnętrznego identyfikatora, korzysta z konkretnej karty SIM. W przypadku korzystania z układu SIM powstaje wyjątkowa sytuacja, w której zewnętrzny identyfikator jednoznacznie identyfikuje konkretne urządzenie!
Co więcej, z jednym IMSI można powiązać kilka identyfikatorów zewnętrznych - jeszcze ciekawsza sytuacja powstaje, gdy identyfikator zewnętrzny 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 obejmuje zestaw indywidualnych zewnętrznych identyfikatorów. Teraz za pomocą jednego żądania skierowanego do SCEF, AS może inicjować operacje grupowe – wysyłając dane lub polecenia sterujące do wielu urządzeń połączonych w jedną logiczną grupę.
Ze względu na fakt, że przejście na nowy identyfikator urządzenia nie może być natychmiastowe dla twórców systemów autonomicznych (AS), SCEF pozostawił możliwość komunikacji systemu autonomicznego (AS) z UE za pomocą standardowego numeru – MSISDN.
Dostarczanie danych bez protokołu IP (NIDD)
W NB-IoT, w kontekście optymalizacji mechanizmów transmisji małych danych, oprócz dotychczasowych typów PDN, takich jak IPv4, IPv6 i IPv4v6, pojawił się kolejny typ – non-IP. W tym przypadku urządzeniu (UE) nie jest przypisywany adres IP, a dane są przesyłane bez użycia protokołu IP. Ruch dla takich połączeń może być kierowany na dwa sposoby: klasycznie - MME -> SGW -> PGW i dalej poprzez tunel PtP do AS (rys. 2) lub z wykorzystaniem SCEF (rys. 3).
Klasyczna metoda nie posiada żadnych szczególnych zalet w porównaniu z ruchem IP, poza redukcją rozmiaru przesyłanych pakietów dzięki braku nagłówków IP. Użycie SCEF otwiera szereg nowych możliwości i znacznie upraszcza procedury interakcji z urządzeniami.
Przesyłając dane za pomocą SCEF, ujawniają się dwie bardzo ważne zalety w porównaniu z klasycznym ruchem IP:
Dostarczanie ruchu MT do urządzenia za pośrednictwem zewnętrznego identyfikatora
Aby wysłać wiadomość do klasycznego urządzenia IP, system autonomiczny musi znać jego adres IP. Tutaj pojawia się problem: ponieważ urządzenie po rejestracji otrzymuje zazwyczaj „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 szarych i białych adresów IP obowiązuje przez ograniczony czas, w zależności od ustawień NAT. Średnio dla TCP i UDP - nie dłużej niż pięć minut. Oznacza to, że jeśli w ciągu 5 minut nie nastąpi żadna wymiana danych z tym urządzeniem, połączenie zostanie zerwane, a urządzenie nie będzie już dostępne pod białym adresem, za pomocą którego zainicjowano sesję z systemem autonomicznym (AS). Istnieje kilka rozwiązań:
1. Użyj bicia serca. Po nawiązaniu połączenia urządzenie musi co kilka minut wymieniać pakiety z systemem autonomicznym (SA), zapobiegając w ten sposób zamknięciu translacji w NAT. Ale nie może być tutaj mowy o jakiejkolwiek efektywności energetycznej.
2. Za każdym razem, gdy zachodzi potrzeba sprawdzenia obecności pakietów dla urządzenia w systemie autonomicznym (AS), należy wysłać wiadomość do łącza w górę.
3. Utwórz prywatną sieć APN (VRF), w której 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 prawie niemożliwe do zrealizowania, jeśli mówimy o flocie składającej się z tysięcy, dziesiątków tysięcy urządzeń.
4. Na koniec, najbardziej odpowiednia opcja: użyj protokołu IPv6. Nie wymaga on NAT, ponieważ adresy IPv6 są dostępne bezpośrednio z Internetu. Jednak nawet w tym przypadku po ponownej rejestracji urządzenie otrzyma nowy adres IPv6 i nie będzie już dostępne za pośrednictwem poprzedniego.
W związku z tym konieczne jest wysłanie do serwera pakietu inicjalizacyjnego zawierającego identyfikator urządzenia, aby przekazać nowy adres IP urządzenia. Następnie należy poczekać na pakiet potwierdzający od AS, który również ma wpływ na efektywność energetyczną.
Metody te sprawdzają się w przypadku urządzeń 2G/3G/LTE, w których nie ma ścisłych wymagań dotyczących autonomii, a co za tym idzie, nie ma ograniczeń dotyczących czasu transmisji danych i transferu danych. Metody te nie nadają się do stosowania w NB-IoT ze względu na wysokie zużycie energii.
SCEF rozwiązuje ten problem: ponieważ jedynym identyfikatorem urządzenia dla systemu autonomicznego jest identyfikator zewnętrzny, system autonomiczny musi wysłać do SCEF tylko pakiet danych dla określonego identyfikatora zewnętrznego, a SCEF zajmie się resztą. Jeśli urządzenie znajduje się w trybie oszczędzania energii PSM lub eDRX, dane zostaną zbuforowane i dostarczone, gdy urządzenie stanie się dostępne. Jeżeli urządzenie jest gotowe do odbioru danych, zostaną one dostarczone natychmiast. To samo dotyczy poleceń zarządzania.
System autonomiczny może w dowolnym momencie odwołać zbuforowaną wiadomość do UE lub zastąpić ją nową.
Mechanizm buforowania można również zastosować przy przesyłaniu danych MO z UE do AS. Jeżeli SCEF nie jest w stanie natychmiast dostarczyć danych do systemu autonomicznego (SA), na przykład gdy na serwerach AS trwają prace konserwacyjne, pakiety te zostaną zbuforowane i zagwarantowane zostanie ich dostarczenie, gdy tylko system autonomiczny stanie się dostępny.
Jak wspomniano powyżej, dostęp do konkretnej usługi i UE dla systemu autonomicznego (AS) (a NIDD jest usługą) jest regulowany przez zasady i polityki obowiązujące po stronie SCEF, co daje wyjątkową możliwość jednoczesnego korzystania z danych z jednego UE przez kilka systemów autonomicznych. Te. Jeżeli kilka systemów autonomicznych (AS) subskrybuje jeden system UE, to po otrzymaniu danych z UE SCEF prześle je do wszystkich subskrybujących systemów autonomicznych. Rozwiązanie to sprawdza się w przypadkach, w których twórca floty specjalistycznych urządzeń dzieli się danymi pomiędzy wieloma klientami. Przykładowo, tworząc sieć stacji meteorologicznych działających w oparciu o technologię NB-IoT, można sprzedawać pochodzące z nich dane wielu usługom jednocześnie.
Gwarantowany mechanizm dostarczania wiadomości
Reliable Data Service to mechanizm gwarantujący dostarczanie komunikatów MO i MT bez konieczności korzystania ze specjalistycznych algorytmów na poziomie protokołu, takich jak np. uzgadnianie w protokole TCP. Działa poprzez dodanie specjalnej flagi do części serwisowej wiadomości podczas wymiany pomiędzy UE i SCEF. O tym, czy ten mechanizm ma zostać aktywowany podczas przesyłania ruchu, decyduje AS.
Jeżeli mechanizm jest aktywny, UE dołącza specjalną flagę do części serwisowej pakietu, jeżeli wymagane jest zagwarantowane dostarczenie ruchu MO. Po otrzymaniu takiego pakietu SCEF odpowiada UE potwierdzeniem odbioru. Jeżeli UE nie otrzyma pakietu potwierdzającego, pakiet zostanie przekazany do SCEF. To samo dzieje się w przypadku ruchu MT.
Urządzenia monitorujące (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łu danych są optymalizacjami (choć bardzo poważnymi) już istniejących procedur, to MONTE jest zupełnie nową funkcjonalnością, niedostępną w sieciach 2G/3G/LTE. MONTE umożliwia AS monitorowanie parametrów urządzenia, takich jak status połączenia, dostępność komunikacji, lokalizacja, status roamingu itp. Omówimy każdy z nich bardziej szczegółowo nieco później.
Gdy zachodzi konieczność aktywacji dowolnego zdarzenia monitorującego dla urządzenia lub grupy urządzeń, system autonomiczny (AS) subskrybuje odpowiednią usługę, wysyłając polecenie odpowiedniego interfejsu API MONTE do SCEF, które obejmuje takie parametry, jak identyfikator zewnętrzny lub identyfikator grupy zewnętrznej, identyfikator systemu autonomicznego (AS), typ monitorowania i liczbę raportów, które system autonomiczny chce otrzymać. Jeżeli system autonomiczny jest upoważniony do realizacji żądania, SCEF przekaże zdarzenie do serwera HSS lub MME, w zależności od typu (rysunek 4). Gdy wystąpi zdarzenie, MME lub HSS generuje raport dla SCEF, który wysyła go do systemu autonomicznego (SA).
Wszystkie zdarzenia, z wyjątkiem „Liczby UE obecnych na obszarze geograficznym”, są dostarczane za pośrednictwem HSS. Dwa zdarzenia: „Zmiana powiązania IMSI-IMEI” i „Status roamingu” są monitorowane bezpośrednio na HSS, pozostałe są dostarczane przez HSS do MME.
Wydarzenia mogą mieć charakter jednorazowy lub okresowy i są determinowane przez ich typ.
Raport o zdarzeniu wysyłany jest przez węzeł monitorujący zdarzenie bezpośrednio do SCEF (rys. 5).
Ważny punkt: Monitorowanie zdarzeń można stosować zarówno do urządzeń nie-IP podłączonych przez SCEF, jak i do urządzeń IP przesyłających dane w klasyczny sposób przez MME-SGW-PGW.
Przyjrzyjmy się bliżej każdemu z wydarzeń monitorowanych:
Utrata łączności — informuje system autonomiczny, że UE nie jest już dostępna ani do przesyłania danych, ani do wymiany sygnałów. Zdarzenie następuje, gdy w MME wygaśnie „czas dostępności mobilnej” dla UE. We wniosku o ten typ monitorowania, system autonomiczny (AS) może określić wartość „Maksymalnego czasu wykrywania” – jeśli UE nie wykaże żadnej aktywności w tym czasie, system autonomiczny (AS) zostanie poinformowany, że UE jest niedostępny, podając przyczynę. Zdarzenie to ma miejsce również w przypadku, gdy UE zostanie siłą usunięte przez sieć z jakiegokolwiek powodu.
* Aby sieć wiedziała, że urządzenie jest nadal dostępne, okresowo inicjuje procedurę aktualizacji obszaru śledzenia (TAU). Częstotliwość tej procedury ustalana jest przez sieć za pomocą timera T3412 lub (T3412_extended w przypadku PSM), którego wartość przekazywana jest do urządzenia w trakcie procedury Attach lub kolejnego TAU. Licznik czasu dostępności mobilnej jest zwykle o kilka minut dłuższy niż T3412. Jeżeli UE nie utworzy TAU przed upływem „czasu dostępności mobilnej”, sieć uznaje, że UE nie jest już osiągalna.
Dostępność UE – Wskazuje, kiedy UE staje się dostępna dla ruchu DL lub SMS. Dzieje się tak, gdy UE włącza obsługę stronicowania (w przypadku UE w trybie eDRX) lub gdy UE przechodzi w tryb ECM-CONNECTED (w przypadku UE w trybie PSM lub eDRX), tj. tworzy TAU lub wysyła pakiet łącza w górę.
Raportowanie lokalizacji – Ten typ zdarzeń monitorujących umożliwia systemowi autonomicznemu żądanie danych o lokalizacji UE. Można zażądać informacji o bieżącej lokalizacji lub ostatniej znanej lokalizacji (określonej na podstawie identyfikatora komórki, z której urządzenie wykonało operację TAU lub przesłało dane ostatnim razem), co jest istotne w przypadku urządzeń w trybach oszczędzania energii PSM lub eDRX. W przypadku „Bieżącej lokalizacji” system autonomiczny może zażądać powtarzających się raportów. W takim przypadku MME będzie informować system autonomiczny za każdym razem, gdy zmieni się lokalizacja urządzenia.
Zmiana stowarzyszenia IMSI-IMEI – Po aktywacji tego zdarzenia SCEF rozpoczyna monitorowanie zmian w parze IMSI (identyfikator karty SIM) i IMEI (identyfikator urządzenia). Gdy wystąpi jakieś zdarzenie, AS zostanie o tym poinformowany. Może służyć do automatycznego ponownego łączenia zewnętrznego identyfikatora z urządzeniem podczas planowanych prac wymiennych lub jako identyfikator urządzenia w przypadku kradzieży.
Status roamingu – tego typu monitorowanie jest wykorzystywane przez AS w celu ustalenia, czy UE znajduje się w sieci macierzystej, czy w sieci partnera roamingowego. Opcjonalnie można przesłać numer PLMN (Public Land Mobile Network) operatora, u którego zarejestrowano urządzenie.
Błąd w komunikacji — Ten typ monitorowania informuje system autonomiczny o błędach w komunikacji z urządzeniem, na podstawie przyczyn niepowodzenia połączenia (kod przyczyny zwolnienia) otrzymanych z sieci dostępu radiowego (protokół S1-AP). To zdarzenie może pomóc ustalić, czy awaria komunikacji nastąpiła z powodu problemów sieciowych, takich jak przeciążenie eNodeb (brak dostępnych zasobów radiowych), czy z powodu awarii samego urządzenia (utrata połączenia radiowego z UE).
Dostępność po awarii DDN – zdarzenie to informuje system autonomiczny (AS), że urządzenie stało się dostępne po awarii komunikacji. Można z niego skorzystać, gdy zachodzi potrzeba przesłania danych do urządzenia, ale poprzednia próba zakończyła się niepowodzeniem, gdyż UE nie odpowiedziało na powiadomienie z sieci (paging) i dane nie zostały dostarczone. Jeżeli ten typ monitorowania został zażądany dla UE, to gdy tylko urządzenie nawiąże komunikację przychodzącą, utworzy TAU lub wyśle dane do łącza w górę, system autonomiczny zostanie poinformowany, że urządzenie stało się dostępne. Ponieważ procedura DDN (powiadomienia o danych w łączu wstecznym) działa pomiędzy MME i S/P-GW, ten typ monitorowania jest dostępny tylko dla urządzeń IP.
Stan łączności PDN – informuje AS o zmianie statusu urządzenia (status łączności PDN) – połączeniu (aktywacja PDN) lub rozłączeniu (usunięcie PDN). System autonomiczny może za jego pomocą nawiązać komunikację z UE lub odwrotnie, aby zrozumieć, że dalsza komunikacja nie jest możliwa. Ten typ monitorowania jest dostępny dla urządzeń IP i nie-IP.
Liczba jednostek UE obecnych na danym obszarze geograficznym – tego typu monitorowanie jest wykorzystywane przez AS do określania liczby UE na określonym obszarze geograficznym.
Wyzwalanie urządzenia)
W sieciach 2G/3G procedura rejestracji w sieci przebiegała dwuetapowo: najpierw urządzenie rejestrowało się w SGSN (procedura dołączania), następnie, gdy zachodziła konieczność przesłania danych, aktywowało kontekst PDP – połączenie z bramą pakietów (GGSN). W sieciach 3G obie te procedury miały charakter sekwencyjny, tzn. urządzenie nie czekało do momentu, w którym konieczne było przesłanie danych, lecz aktywowało PDP natychmiast po zakończeniu procedury dołączania. W LTE te dwie procedury połączono w jedną, tzn. po podłączeniu urządzenie natychmiast żądało aktywacji połączenia PDN (analogicznego do PDP w 2G/3G) poprzez eNodeB do MME-SGW-PGW.
W NB-IoT zdefiniowano metodę połączenia zwaną „podłączanie bez PDN”, co oznacza, że UE nawiązuje połączenie bez nawiązywania połączenia PDN. W tym przypadku nie ma możliwości przesyłania danych, możliwe jest jedynie odbieranie lub wysyłanie wiadomości SMS. Aby przesłać do takiego urządzenia polecenie aktywacji PDN i połączenia z systemem autonomicznym (AS), opracowano funkcjonalność „Wyzwalanie urządzenia”.
Po otrzymaniu polecenia połączenia takiego UE z systemu autonomicznego (AS), SCEF inicjuje wysłanie SMS-a sterującego do urządzenia za pośrednictwem centrum SMS. Po otrzymaniu wiadomości SMS urządzenie aktywuje sieć PDN i łączy się z systemem autonomicznym (AS) w celu odebrania kolejnych instrukcji lub przesłania danych.
Mogą zdarzyć się sytuacje, w których subskrypcja SCEF dla danego urządzenia wygaśnie. Tak, abonament ma swój okres ważności, ustalony przez operatora lub uzgodniony z AS. Po wygaśnięciu PDN zostanie dezaktywowana w MME, a urządzenie stanie się niedostępne dla systemu autonomicznego. W tym przypadku przydatna okaże się również funkcja „Wyzwalanie urządzenia”. Po otrzymaniu nowych danych z AS, SCEF określi stan połączenia urządzenia i prześle dane poprzez kanał SMS.
wniosek
Funkcjonalność SCEF oczywiście nie ogranicza się do usług opisanych powyżej — jest ona stale rozwijana i poszerzana. Obecnie na potrzeby SCEF ujednolicono już kilkanaście usług. Na razie poruszyliśmy tylko najważniejsze funkcje, których oczekują programiści; O reszcie opowiemy w przyszłych artykułach.
Natychmiast nasuwa się pytanie: w jaki sposób uzyskać dostęp testowy do tego „cudownego” węzła, aby umożliwić wstępne testowanie i debugowanie możliwych przypadków? Wszystko jest bardzo proste. Każdy programista może wysłać zapytanie na adres iot.info@mts.ru, w którym wystarczy wskazać cel połączenia, opisać możliwy przypadek i podać dane kontaktowe do komunikacji.
Do następnego razu!
Autorzy:
- Starszy ekspert działu rozwiązań konwergentnych i usług multimedialnych Siergiej Nowikow ,
- ekspert działu rozwiązań konwergentnych i usług multimedialnych Aleksiej Łapszyn
Źródło: www.habr.com
