A cikkben „”, a NB-IoT hálózati csomagmag-architektúrájáról beszélve említettük az új SCEF csomópont megjelenését. A harmadik részben magyarázzuk el, mi is ez és miért van szükség rá?
M2M szolgáltatás létrehozásakor az alkalmazásfejlesztők a következő kérdésekkel találkoznak:
- hogyan azonosítsák az eszközöket;
- milyen hitelesítési és ellenőrzési algoritmust használjanak;
- milyen szállítási protokollt válasszanak az eszközökkel való kommunikációhoz;
- hogyan biztosítsák az adatok megbízható továbbítását az eszközökre;
- hogyan alakítsák ki és állítsák be az adatcsere szabályait velük;
- hogyan ellenőrizzék és kapjanak online információt állapotukról;
- hogyan küldjenek adatokat egyszerre egy csoport eszköznek;
- hogyan küldjenek adatokat egy eszközről több kliensnek;
- hogyan érjék el az operátor kiegészítő szolgáltatásait az eszköz kezeléséhez egységesen.
Ezek megoldásához sajátos, technikailag „nehéz” megoldásokat kell létrehozni, ami megnöveli a munkaerő-igényt és a szolgáltatások piacra jutási idejét. Itt jön a képbe az új SCEF csomópont.
A 3GPP meghatározása szerint a SCEF (szolgáltatáskapacitás-kihelyezési funkció) egy teljesen új összetevője a 3GPP architektúrának, amelynek feladata a szolgáltatások és funkciók biztonságos kihelyezése a 3GPP hálózati interfészein keresztül API-n.
Egyszerűen fogalmazva a SCEF egy közvetítő az alkalmazási szerver (application server — AS) és a hálózat között, egyetlen hozzáférési ablak az operátor M2M eszközének kezelésére vonatkozó szolgáltatásokhoz az NB-IoT hálózaton keresztül intuitív, szabványosított API interfészen keresztül.
A SCEF elrejti a szolgáltató hálózatának bonyolultságát, lehetővé téve az alkalmazásfejlesztők számára, hogy elvonatkoztassanak a bonyolult, specifikus eszközkommunikációs mechanizmusoktól.
A hálózati protokollok alkalmazásfejlesztők számára ismerős API interfésszé történő átkonvertálásával a SCEF megkönnyíti új szolgáltatások létrehozását és csökkenti a piacra jutási időt. Az új csomópont az eszköz és AS közötti adatcsere szabályainak meghatározására, valamint a mobil eszközök azonosítási/ hitelesítési funkcióinak ellátására is alkalmas, levéve a fejlesztők válláról ezeket a funkciókat, áthelyezve e funkciókat az operátorra.
A SCEF összegyűjti az alkalmazásszerverek hitelesítéséhez és engedélyezéséhez, az UE mobilitás fenntartásához, adatátvitelhez és eszközök aktiválásához, a szolgáltatásokhoz és a hálózati lehetőségekhez való hozzáféréshez szükséges interfészeket.
Az AS felé egyetlen T8 interfész működik, amely API-interfész (HTTP/JSON), a 3GPP által szabványosítva. Minden interfész, a T8 kivételével, a DIAMETER protokollon alapul (1. ábra).
A T6a interfész a SCEF és az MME között található. Használják a mobilitási/sessziókezelési eljárásokhoz, non-IP adatok átviteléhez, eseménymonitorozáshoz és az ezekről szóló jelentések fogadásához.
A S6t interfész a SCEF és az HSS között helyezkedik el. Szükséges az előfizető hitelesítéséhez, az alkalmazásszerverek engedélyezéséhez, az external ID és az IMSI/MSISDN páros megszerzéséhez, eseménymonitorozáshoz és az ezekről szóló jelentések fogadásához.
A S6m/T4 interfészek a SCEF-től az HSS-ig és az SMS-C-ig terjednek (a 3GPP meghatározza az MTC-IWF csomópontot, amelyet az eszközök aktiválására és SMS-ek továbbítására használnak az NB-IoT hálózatokban. Azonban minden megvalósításnál ennek a csomópontnak a funkciója integrálva van a SCEF-be, ezért az ábra egyszerűsítése érdekében nem vizsgáljuk külön). Ezeket SMS küldési útvonal-információk beszerzésére és az SMS központtal való interakcióra használják.
A T8 az API-interfész, amely lehetővé teszi a SCEF és az alkalmazásszerverek közötti interakciót. Ezen az interfészen keresztül küldenek vezérlő parancsokat és forgalmat egyaránt.
*a valóságban több interfész létezik, itt csak a legfontosabbakat soroltuk fel. A teljes lista a 3GPP 23.682 (4.3.2 Referenciapontok listája) dokumentumban található.
Az alábbiakban a SCEF kulcsfontosságú funkciói és szolgáltatásai találhatók:
- a SIM-kártya azonosítójának (IMSI) hozzárendelése az external ID-hez;
- non-IP forgalom átvitele (Non-IP Data Delivery, NIDD);
- csoportos műveletek, az external group ID használatával;
- megerősített adatszállítási mód támogatása;
- MO (Mobile Originated) és MT (Mobile Terminated) adatok pufferelése;
- eszközök és alkalmazásszerverek hitelesítése és engedélyezése;
- egy UE az adatok egyidejű használata több AS által;
- speciális UE állapotellenőrző funkciók támogatása (MONTE – Monitoring Events);
- eszközök aktiválása;
- non-IP adatok roamingjának biztosítása.
Az AS és a SCEF közötti interakció fő elve a úgynevezett előfizetések séma alapján épül fel. Amikor hozzáférésre van szükség egy adott szolgáltatáshoz a SCEF számára egy adott UE esetében, az alkalmazásszervernek létre kell hoznia egy előfizetést, egy parancsot küldve a kért szolgáltatás konkrét API-jára, és válaszként megkapja az egyedi azonosítót. Ezt követően minden további lépést és kommunikációt a UE-vel ezen az azonosítón keresztül végeznek az adott szolgáltatáson belül.
Külső azonosító: az eszköz univerzális azonosítója
Az AS és az eszközök közötti interakciós séma egyik legfontosabb változása a SCEF-en keresztüli munkavégzés során a univerzális azonosító bevezetése. Mostantól a telefonos szám (MSISDN) vagy IP cím helyett, ahogyan azt a klasszikus 2G/3G/LTE hálózatban tették, az alkalmazásszerver számára az eszköz azonosítója az "external ID". Ez egy szabvány által meghatározott, a fejlesztők számára megszokott formátumban van: "@".
A fejlesztőknek már nincs szükségük eszközautentikáló algoritmusok megvalósítására, a hálózat teljes mértékben átvette ezt a funkciót. Az external ID az IMSI-hez van kötve, és a fejlesztő biztos lehet abban, hogy amikor egy adott external ID-hez fordul, akkor egy konkrét SIM-kártyával interakcióba lép. SIM-chip használatakor egy igazán egyedi helyzet áll elő, amikor az external ID egyértelműen azonosít egy adott eszközt!
Sőt, egy IMSI-hez több külső azonosító is hozzárendelhető - ez még érdekesebb szituációt teremt, amikor az external ID egyértelműen azonosítja azt a konkrét alkalmazást, amely felelős egy adott szolgáltatásért egy adott eszközön.
Megjelenik a csoportazonosító is - external group ID, amely tartalmaz egy sor különálló external ID-t. Mostantól egyetlen kérésre a SCEF AS csoportos műveleteket indíthat - adatokat vagy vezérlő parancsokat küldhet több eszköznek, amelyek egy logikai csoportba tartoznak.
Arra tekintettel, hogy az AS fejlesztőinek a váltás az új eszközazonosítóra nem lehet azonnali, a SCEF lehetőséget biztosított az AS és az UE közötti kommunikációra a hagyományos számmal - MSISDN.
Nem-IP forgalom továbbítása (Non-IP Data Delivery, NIDD)
Az NB-IoT keretein belül a kis adatátviteli mechanizmusok optimalizálásának érdekében, az már meglévő PDN típusok, mint az IPv4, IPv6 és IPv4v6 mellett, megjelent egy új típus — a non-IP. Itt az eszköz (UE) nem kap IP-címet, és az adatok IP-protokoll használata nélkül kerülnek átvitelre. Az ilyen típusú kapcsolatok forgalma két módon irányítható: klasszikus módon — MME -> SGW -> PGW, majd PtP alagúton keresztül az AS-hez (lásd 2. ábra), vagy SCEF használatával (lásd 3. ábra).
A klasszikus módszer nem hordoz különösebb előnyöket az IP-forgalommal szemben, kivéve a csomagok méretének csökkentését az IP-fejlécek hiánya miatt. A SCEF használata viszont számos új lehetőséget nyit meg, és jelentősen leegyszerűsíti az eszközökkel való interakciós folyamatokat.
Adatátvitel SCEF használatával két nagyon fontos előnyt jelent a klasszikus IP-forgalomhoz képest:
MT forgalom kézbesítése az eszközhöz külső azonosító alapján
Ahhoz, hogy klasszikus IP-eszközre üzenetet küldjünk — az AS-nek ismernie kell az IP-címét. Itt egy probléma merül fel: mivel az eszköz regisztrációja során jellemzően „szürke” IP-címet kap, az interneten található alkalmazásszerverrel NAT csomóponton keresztül, ahol a szürke cím átalakítása történt fehér címre. A szürke és fehér IP-címek közötti összeköttetés korlátozott ideig áll fenn, a NAT beállításaitól függően. TCP vagy UDP esetében a mágus általában nem haladja meg az öt percet. Tehát ha 5 percig nem történik adatforgalom az eszközzel, az összeköttetés megszűnik, és az eszköz nem lesz elérhető azon a fehér címen, amelyen a szoftver kezdete történt. Néhány megoldás létezik:
1. Használjon heartbeat-et. Miután az összeköttetés létrejött, az eszköznek az AS-sel kell adatcsomagokat cserélnie néhány percenként, ezzel megakadályozva a NAT fordítást. De ez nem tekinthető energiatakarékos megoldásnak.
2. Minden egyes alkalommal, amikor szükséges, ellenőrizze az eszköz csomagjait az AS-nál — üzenetet küldeni az uplinkbe.
3. Magán APN (VRF) létrehozása, ahol az alkalmazásszerver és az eszközök ugyanabban az alhálózatban találhatóak, és statikus IP-címeket rendelni az eszközökhöz. Ez működni fog, de szinte lehetetlenné válik, amikor több ezer, tucatnyi ezer eszközről van szó.
4. Végül a legmegfelelőbb opciónak az IPv6 használata bizonyul: ez esetben nem szükséges NAT, mivel az IPv6 címek közvetlenül elérhetők az internetről. Azonban még ebben az esetben is, ha a készüléket újra regisztrálják, új IPv6 címet kap, és már nem lesz elérhető a korábbi címen.
Ezért küldeni kell egy inicializáló csomagot a készülék azonosítójával a szerverre, hogy jelezze az új IP-címet. Ezután várni kell a megerősítő csomagra az AS-tól, ami szintén befolyásolja az energiahatékonyságot.
Ezek a módszerek jól működnek 2G/3G/LTE eszközök esetén, ahol a készülékkel szemben nincsenek szigorú követelmények az üzemidőre, így nincsenek korlátozások az adásidő és a forgalom vonatkozásában. Az NB-IoT esetében ezek a módszerek nem alkalmazhatók nagy energiafelhasználásuk miatt.
A SCEF megoldja ezt a problémát: mivel a készülék egyetlen azonosítója az AS számára az external ID, az AS-nek elegendő egy adatcsomagot küldenie a SCEF-hez egy adott external ID-val, minden egyébben a SCEF fog járni. Ha a készülék energiatakarékos módba (PSM vagy eDRX) kerül, az adatok pufferezve lesznek, és akkor kerülnek továbbításra, amikor a készülék elérhetővé válik. Ha a készülék elérhető a forgalom számára, az adatok azonnal át lesznek adva. Ez érvényes a vezérlési parancsokra is.
Bármikor az AS visszavonhat egy pufferezett üzenetet a UE irányába, vagy újra cserélheti.
A pufferezési mechanizmus a MO-adatok UE-ből AS felé történő átadására is alkalmazható. Ha a SCEF nem tudta azonnal eljuttatni az adatokat az AS-hez, például ha karbantartás folyik az AS szerverein, ezek a csomagok pufferezve lesznek, és garantáltan el lesznek juttatva, amint az AS elérhetővé válik.
Ahogy azt fentebb említettük, egy konkrét szolgáltatáshoz és UE-hez való hozzáférést az AS részére (mivel a NIDD egy szolgáltatás) a SCEF oldalán található szabályok és politikák szabályozzák, ami lehetővé teszi, hogy egyidejűleg több AS használja ugyanazon UE adatait. Tehát ha több AS feliratkozott egy UE-re, akkor az UE-ből érkező adatok vételét követően a SCEF azokat minden feliratkozott AS-nek továbbítja. Ez jól illeszkedik azokhoz az esetekhez, amikor egy speciális eszközpark létrehozója több ügyfél között osztja meg az adatokat. Például egy NB-IoT-n működő időjárás-állomás hálózat létrehozásával az azokból származó adatokat egyszerre több szolgáltatásnak is értékesíthetjük.
A biztosított üzenetküldés mechanizmusa
Megbízható Adatszolgáltatás — a MO és MT üzenetek biztosított küldésének mechanizmusa, speciális algoritmusok, például a TCP handshake szintű protokollok használata nélkül. A rendszer egy speciális jelző bekapcsolásával működik az üzenet kezelési részében az UE és a SCEF közötti cserénél. Az, hogy ezt a mechanizmust aktiváljuk-e a forgalom átvitelnél, az AS döntése.
Ha a mechanizmus aktiválva van, az UE szükség esetén, a MO forgalom biztosított küldéséhez speciális jelzőt kapcsol be a csomag kezelési részében. Ha a SCEF ilyen csomagot kap, válaszként megerősítést küld az UE-nek. Ha az UE nem kapja meg a megerősítő csomagot, a csomagot a SCEF felé újra küldik. Ugyanez történik az MT forgalom esetén is.
Eszközmonitoring (monitoring events - MONTE)
Ahogy már korábban említettük, a SCEF funkciói közé tartozik a UE állapotának figyelése, azaz az eszközmonitoring. Míg az új azonosítók és adatátviteli mechanizmusok a meglévő eljárások optimalizálásai (bár meglehetősen jelentős), a MONTE egy teljesen új funkció, amely nem elérhető a 2G/3G/LTE hálózatokban. A MONTE lehetővé teszi az AS számára, hogy figyelje az eszköz állapotát, például a kapcsolódás állapotát, a kommunikációra való elérhetőséget, a helymeghatározást és a roaming státuszt stb. Részletesebben a továbbiakban fogunk beszélni mindegyikről.
Ha szükséges, hogy egy monitoring eseményt aktiváljunk egy eszközön vagy eszközcsoporton, az AS feliratkozik a megfelelő szolgáltatásra azzal, hogy a SCEF-nek elküld egy MONTE API megfelelő parancsát, amely tartalmazza az olyan paramétereket, mint az external Id vagy external group ID, az AS azonosítója, a monitoring típusa, valamint a riportok száma, amelyet az AS szeretne megkapni. Ha az AS jogosult a kérés teljesítésére, a SCEF a típustól függően provizionálja az eseményt az HSS-en vagy az MME-n (lásd a 4. ábrát). Esemény bekövetkezésekor az MME vagy HSS jelentést generál a SCEF felé, amely továbbítja azt az AS-nek.
Minden esemény provizionálása, kivéve a “Number of UEs present in a geographic area”, az HSS-en keresztül történik. Két esemény, a “Change of IMSI-IMEI Association” és a “Roaming Status”, közvetlenül az HSS-en követhető, a többit az HSS az MME-re provizionálja.
Az események lehetnek egyszeri vagy periodikus, attól függően, hogy milyen típusúak.
Az eseményjelentés (reporting) közvetlenül a SCEF-re, az eseményt nyomon követő csomóponton keresztül történik (5. ábra).
Fontos megjegyzés: a nyomon követett események alkalmazhatóak nem IP-es eszközökre, amelyek SCEF-en keresztül csatlakoznak, valamint IP-es eszközökre, amelyek klasszikus módon adatokat továbbítanak az MME-SGW-PGW-n keresztül.
Nézzük meg részletesebben a nyomon követett eseményeket:
Kapcsolat elvesztése – értesíti az AS-t, hogy az UE többé nem elérhető sem adatforgalom, sem jelzéscsere számára. Ez az esemény akkor következik be, ha az MME-nél lejár az "mobile reachability timer" az UE számára. Az AS kérésében megadhatja saját "Maximum Detection Time" értékét – ha ezen időtartam alatt az UE nem mutat aktivitást, az AS értesítést kap, hogy az UE nem elérhető, megnevezve az okot. Ez az esemény akkor is bekövetkezik, ha az UE valamilyen okból kényszerítve lett a hálózat által a leválasztásra.
* Annak érdekében, hogy a hálózat tudja, hogy az eszköz továbbra is elérhető, időszakonként elindítja az aktualizálási eljárást – Tracking Area Update (TAU). Ennek az eljárásnak a gyakoriságát a hálózat a T3412 időzítő segítségével állítja be, vagy (T3412_extended a PSM esetén), amelynek értéke az eszköznek az Attach eljárás vagy egy következő TAU során kerül továbbításra. A mobile reachability timer általában néhány perccel hosszabb, mint a T3412. Ha az UE a "Mobile reachability timer" lejárta előtt nem hajt végre TAU-t, a hálózat úgy véli, hogy az UE elérhetetlenné vált.
UE elérhetőség – Mutatja, mikor válik elérhetővé az UE az DL forgalom vagy SMS számára. Ez akkor történik, amikor az UE elérhetővé válik a paging számára (az eDRX módú UE esetén) vagy amikor az UE ECM-CONNECTED módba lép (a PSM vagy eDRX módú UE esetén), vagyis TAU-t végez, vagy uplink csomagot küld.
Helymeghatározási jelentés – Ez a fajta nyomon követési esemény lehetővé teszi az AS számára, hogy adatokat kérjen az UE helyzetéről. Kérhető vagy a jelenlegi helyzet (Current Location), vagy az utolsó ismert hely (Last Known Location, amelyet a cell ID határoz meg, ahonnan az eszköz TAU-t végzett vagy utoljára forgalmat továbbított), ami releváns az energiatakarékos PSM vagy eDRX módokban lévő eszközök esetében. A "Current Location" esetén az AS kérheti a folyamatos jelentéseket, miközben az MME minden alkalommal értesíti az AS-t, amikor az eszköz helyzete megváltozik.
IMSI-IMEI asszociáció változása – Az esemény aktiválásakor a SCEF elkezdi figyelni az IMSI (SIM-kártya azonosító) és IMEI (eszköz azonosító) párosának változását. Az esemény bekövetkeztekor értesíti az AS-t. Használható arra, hogy automatikusan újra hozzárendelje az external ID-t az eszközhöz tervezett csere munkálatok során, vagy hogy az eszköz lopásának azonosítójaként szolgáljon.
Roaming állapot – ez a típusú megfigyelés az AS által használt, hogy meghatározza, hogy a UE a hazai hálózatban vagy egy roaming partner hálózatában található. Opcionálisan átadható a hálózat PLMN (Public Land Mobile Network) azonosítója, amelybe az eszköz be van jegyezve.
Kommunikációs hiba — Ez a típusú megfigyelés értesíti az AS-t az eszközzel való kommunikációs hibákról, a kapcsolatzáreváláso okai (release cause code) alapján, amelyeket a rádiós hozzáférés hálózattól (S1-AP protokoll) kapott. Ez az esemény segíthet meghatározni, hogy miért következett be a kommunikációs hiba - például hálózati problémák miatt, ha az eNodeb túlterhelt (Rádió erőforrások nem állnak rendelkezésre), vagy az eszköz meghiúsulása miatt (Rádiós kapcsolat az UE-vel megszakadt).
Elérhetőség DDN hiba után – ez az esemény értesíti az AS-t, hogy az eszköz elérhetővé vált a kommunikációs hiba után. Használható, amikor adatokat kell továbbítani az eszközre, de a korábbi kísérlet nem volt sikeres, mivel az UE nem válaszolt a hálózati értesítésre (paging), és az adatok nem kerültek átadásra. Ha ezt a típusú megfigyelést kérték az UE számára, akkor amint az eszköz bejövő kommunikációt folytat, TAU-t hajt végre vagy adatokat küld az uplinkben, az AS tájékoztatva lesz arról, hogy az eszköz elérhetővé vált. Mivel a DDN (downlink data notification) eljárás az MME és az S/P-GW között működik, ez a megfigyelési forma csak IP-eszközök számára érhető el.
PDN csatlakozási állapot – értesíti az AS-t az eszköz állapotának (PDN csatlakozási állapot) megváltozásakor – csatlakozáskor (PDN aktiválása) vagy lecsatlakozáskor (PDN eltávolítása). Ezt az AS használhatja kommunikáció kezdeményezésére az UE-vel, vagy éppen ellenkezőleg, hogy megértse, hogy a kommunikáció már nem lehetséges. Ez a típusú megfigyelés elérhető IP és nem IP eszközök számára.
A földrajzi területen jelen lévő UEs száma – ez a típusú megfigyelés az AS által használt, hogy meghatározza az UE-k számát egy adott földrajzi területen.
Eszközök aktiválása (Device triggering)
A 2G/3G hálózatokban a hálózati regisztráció eljárása kétszintű volt: először az eszköz regisztrálta magát az SGSN-ben (attach eljárás), majd ha szükséges volt az adatok továbbítására, aktiválta a PDP context-et – a csatlakozást a csomagkapuhoz (GGSN). A 3G hálózatokban ez a két eljárás egymás után zajlott, azaz az eszköz nem várta meg, amíg adatokat kell továbbítani, hanem az attach eljárás befejezése után azonnal aktiválta a PDP-t. LTE környezetben ez a két eljárás egyesült, tehát az attach alatt az eszköz azonnal kérte a PDN connection aktiválását (a 2G/3G PDP analógja) az eNodeB-n keresztül MME-SGW-PGW-hoz.
Az NB-IoT-ban meghatározott egy olyan csatlakozási mód, mint az „attach without PDN”, azaz az UE csatlakozik anélkül, hogy PDN-csatlakozást létesítene. Ebben az esetben nem áll rendelkezésre forgalom továbbítására, és csak SMS-t tud küldeni vagy fogadni. Annak érdekében, hogy ilyen eszközre parancsot küldjön a PDN aktiválására és az AS-hez való csatlakozásra – kifejlesztették a „Device triggering” funkciót.
Amikor az AS a csatlakozási parancsot ad az ilyen UE-nek, a SCEF az SMS központon keresztül kezdeményezi egy irányító SMS elküldését az eszközre. Amikor az eszköz megkapja az SMS-t, aktiválja a PDN-t és csatlakozik az AS-hez a további utasítások vagy adatok továbbítása érdekében.
Lehetnek olyan esetek, amikor a SCEF előfizetése az eszközre lejár. Igen, az előfizetésnek van egy eltarthatósági ideje, amelyet az üzemeltető határoz meg, vagy az AS-szel egyeztetettek. Lejárta után az MME-n a PDN deaktiválódik, és az eszköz nem lesz elérhető az AS számára. Ebben az esetben a „Device triggering” funkció is segíthet. Amikor új adatokat kap az AS-től, a SCEF megállapítja az eszköz csatlakozási státuszát, és az adatokat SMS csatornán keresztül szállítja.
Zárás
A SCEF funkciója természetesen nem korlátozódik a fent említett szolgáltatásokra, és folyamatosan fejlődik és bővül. Jelenleg a SCEF számára már több mint egy tucat szolgáltatást standardizáltak. Eddig csak a fejlesztők által legkeresettebb alapvető funkciókat érintettük, a többi részletéről a jövőbeli cikkekben fogunk beszélni.
Azonnal felmerül a kérdés, hogyan lehet hozzáférni ehhez a „csoda”-csomóponthoz a tesztelés és a lehetséges esetek hibakeresésének előzetes tesztelésére? Mindez nagyon egyszerű. Bármely fejlesztő kérdést küldhet az iot.info@mts.ru címre, amelyben elegendő megadni a csatlakozási célt, a lehetséges eset leírását és a kapcsolatfelvételi információkat.
Viszontlátásra!
Szerzők:
- felső szakértő a konvergens megoldások és multimédiás szolgáltatások területén, Novikov Szergej ,
- szakértő a konvergens megoldások és multimédiás szolgáltatások területén, Lapsin Alekszej
Forrás: habr.com
