NB-IoT: jak to funguje? Část 3: SCEF – jednotné okno pro přístup k službám operátora

V článku „NB-IoT: jak to funguje? Část 2“ jsme zmínili architekturu paketového jádra sítě NB-IoT a vznik nového uzlu SCEF. V třetí části vysvětlujeme, co to je a k čemu je to dobré?

Při vytváření M2M služby se vývojáři aplikací potýkají s následujícími otázkami:

• jak identifikovat zařízení;
• jaký použít algoritmus pro ověření a potvrzení pravosti;
• jaký vybrat transportní protokol pro komunikaci s zařízeními;
• jak garantovat doručení dat na zařízení;
• jak organizovat a stanovit pravidla pro výměnu dat s nimi;
• jak kontrolovat a v reálném čase získat informace o jejich stavu;
• jak současně doručit data skupině svých zařízení;
• jak současně poslat data z jednoho zařízení na více klientů;
• jak získat jednotný přístup k dalším službám operátora pro správu svého zařízení.

Pro jejich řešení je často třeba vytvářet proprietární technicky „těžká“ řešení, což zvyšuje náklady na práci a čas potřebný k uvedení služeb na trh. A právě zde přichází nový uzel SCEF na pomoc.

Podle definice 3GPP je SCEF (funkce exponování schopností služeb) zcela novou součástí architektury 3GPP, jejíž funkcí je bezpečné exponování služeb a schopností, které poskytují síťové rozhraní 3GPP prostřednictvím API.

Jednoduše řečeno, SCEF je zprostředkovatel mezi sítí a aplikačním serverem (application server — AS), jediné okno pro přístup k službám operátora pro správu svého M2M zařízení v síti NB-IoT prostřednictvím intuitivního standardizovaného API rozhraní.

SCEF skryje složitost sítě operátora, což umožňuje vývojářům aplikací abstrahovat od složitých, specifických mechanismů interakce s zařízeními.

Díky převodu síťových protokolů na vývojářům známé API rozhraní SCEF usnadňuje vytváření nových služeb a zkracuje čas potřebný k uvedení na trh. Nový uzel také zahrnuje funkce identifikace/autentizace mobilních zařízení a stanovování pravidel pro výměnu dat mezi zařízením a AS, čímž uvolňuje vývojáře aplikací od nutnosti implementovat tyto funkce na své straně a přenáší tyto úkoly na ramena operátora.

SCEF zajišťuje rozhraní potřebná pro autentizaci a autorizaci aplikačních serverů, udržování mobility UE, přenos dat a spouštění zařízení, přístup k dalším službám a funkcím sítě operátora.

Směrem k AS existuje pouze jediné rozhraní T8, API rozhraní (HTTP/JSON), standardizované 3GPP. Všechna rozhraní, kromě T8, fungují na bázi protokolu DIAMETER (obrázek 1).

T6a je rozhraní mezi SCEF a MME. Používá se pro procedury řízení mobility a relací, přenos non-IP dat, provizioning monitorovacích událostí a příjem zpráv o nich.

S6t je rozhraní mezi SCEF a HSS. Je nutné pro autentizaci předplatitele, autorizaci aplikačních serverů, získání páru external ID a IMSI/MSISDN, provizioning monitorovacích událostí a příjem zpráv o nich.

S6m/T4 jsou rozhraní od SCEF k HSS a SMS-C (ve 3GPP je definován uzel MTC-IWF, který se používá pro spouštění zařízení a přenos SMS v sítích NB-IoT. Nicméně ve všech realizacích je funkčnost tohoto uzlu integrována do SCEF, takže pro zjednodušení schématu ho nebudeme zvažovat odděleně). Používají se pro získání směrových informací pro odesílání SMS a interakci se SMS centrem.

T8 je API rozhraní pro interakci SCEF s aplikačními servery. Skrze toto rozhraní se přenášejí jak řídicí příkazy, tak i provoz.

*ve skutečnosti existuje více rozhraní, zde jsou uvedena pouze ta nejzákladnější. Kompletní seznam je uveden ve 3GPP 23.682 (4.3.2 Seznam referenčních bodů).

Níže jsou uvedeny klíčové funkce a služby SCEF:

• přiřazení identifikátoru SIM karty (IMSI) k external ID;
• přenos non-IP provozu (Non-IP Data Delivery, NIDD);
• skupinové operace s použitím external group ID;
• podpora režimu přenosu dat s potvrzením;
• bufferování dat MO (Mobile Originated) a MT (Mobile Terminated);
• autentizace a autorizace zařízení a aplikačních serverů;
• současné používání dat jednoho UE několika AS;
• podpora speciálních funkcí sledování stavu UE (MONTE – Monitoring Events);
• spouštění zařízení;
• zajištění roamingu non-IP dat.

Hlavní princip interakce mezi AS a SCEF je založen na systému tzv. předplatného. Při potřebě získání přístupu k určitému servisu SCEF pro konkrétní UE, je serveru aplikací nutné vytvořit předplatné zasláním příkazu na konkrétní API požadovaného servisu a v odpovědi obdržet jedinečný identifikátor. Poté veškeré další akce a komunikace s UE v rámci tohoto servisu proběhnou s použitím tohoto identifikátoru.

Externí ID: univerzální identifikátor zařízení

Jedním z nejdůležitějších změn v systému interakce AS s zařízeními při práci přes SCEF je vznik univerzálního identifikátoru. Nyní místo telefonního čísla (MSISDN) nebo IP adresy, jak tomu bylo v klasické síti 2G/3G/LTE, se identifikátorem zařízení pro server aplikací stává „externí ID“. Ten je definován standardem v obvyklém formátu pro vývojáře aplikací „@“.

Vývojáři již nemusí implementovat algoritmy pro autentizaci zařízení, síť tuto funkci plně přebírá. Externí ID je spojeno s IMSI a vývojář si může být jistý, že při komunikaci s konkrétním externím ID interaguje s konkrétní SIM kartou. Při použití SIM čipu vzniká dokonce unikátní situace, kdy externí ID jednoznačně identifikuje konkrétní zařízení!

Navíc lze k jednomu IMSI přiřadit více externích ID — to vytváří ještě zajímavější situaci, kdy externí ID jednoznačně identifikuje konkrétní aplikaci odpovídající za určitou službu na konkrétním zařízení.

Také vzniká skupinový identifikátor — externí skupinové ID, které zahrnuje sadu jednotlivých externích ID. Nyní jedním požadavkem na SCEF může AS iniciovat skupinové operace — zaslání dat nebo příkazů pro řadu zařízení spojených do jediné logické skupiny.

Z důvodu toho, že pro vývojáře AS přechod na nový identifikátor zařízení nemůže být okamžitý, SCEF ponechal možnost komunikace AS s UE prostřednictvím standardního čísla – MSISDN.

Přenos non-IP provozu (Non-IP Data Delivery, NIDD)

Ve NB-IoT, v rámci optimalizace mechanismů přenosu malých objemů dat, se vedle již existujících typů PDN, jako jsou IPv4, IPv6 a IPv4v6, objevil ještě jeden typ — non-IP. V tomto případě není zařízení (UE) přiřazen žádný IP adresa a data jsou přenášena bez použití protokolu IP. Pro tyto připojení může být provoz směrován dvěma způsoby: klasickým — MME -> SGW -> PGW a dále přes PtP tunel do AS (obr. 2) nebo pomocí SCEF (obr. 3).

Klasický způsob nenabízí žádné zvláštní výhody oproti IP provozu, kromě zmenšení velikosti přenášených paketů díky absenci IP hlaviček. Použití SCEF však otevírá celou řadu nových možností a výrazně zjednodušuje postupy interakce se zařízeními.

Při přenosu dat přes SCEF se objevují dvě velmi důležité výhody oproti klasickému IP provozu:

Dodání MT provozu k zařízení podle externího ID.

Aby bylo možné poslat zprávu na klasické IP zařízení, musí AS znát jeho IP adresu. Tady nastává problém: protože zařízení obvykle při registraci získává "šedou" IP adresu, komunikuje se serverem aplikací, který se nachází v internetu, přes uzel NAT, kde probíhá překlad šedé adresy na bílou. Svazek šedé a bílé IP adresy drží omezený čas, v závislosti na nastavení NAT. Průměrně pro TCP nebo UDP — ne více než pět minut. To znamená, že pokud v průběhu 5 minut nedochází k výměně dat s tímto zařízením, svazek se rozpadne a zařízení přestane být dostupné na té bílé adrese, se kterou byla zahájena relace s AS. Existuje několik řešení:

1. Používat heartbeat. Jakmile je spojení navázáno, zařízení by mělo vyměňovat s AS pakety každých několik minut, čímž by zabránilo uzavření překladů v NAT. Ale zde nemůže být řeč o žádné energetické efektivnosti.

2. Pokaždé, když je potřeba zkontrolovat existenci paketů pro zařízení na AS — posílat zprávu v uplink.

3. Vytvořit soukromý APN (VRF), kde server aplikací a zařízení budou v jedné podsíti, a přidělit zařízením statické IP adresy. Bude to fungovat, ale je to téměř nerealizovatelné, když jde o park tisíců, desítek tisíců zařízení.

4. Nakonec je nejvhodnější možnost: použít IPv6, pro něj není potřeba NAT, protože IPv6 adresy jsou přímo dostupné z internetu. Avšak i v tomto případě, při opětovné registraci zařízení, dostane nové IPv6 adresy a nebude již dostupné podle předchozího.

Je tedy nutné odeslat nějaký iniciační paket s identifikátorem zařízení na server, aby se oznámila nová IP adresa zařízení. Poté čekat na potvrzující paket od AS, což také ovlivňuje energetickou účinnost.

Tyto metody dobře fungují pro 2G/3G/LTE zařízení, kde nejsou kladeny přísné požadavky na autonomie a, následně, nejsou žádná omezení na čas v éteru a na trafik. Pro NB-IoT tyto metody nejsou vhodné z důvodu vysoké energetické náročnosti.

SCEF tento problém řeší: jelikož jediným identifikátorem zařízení pro AS je external ID, stačí, aby AS poslal datový paket na SCEF pro konkrétní external ID, o vše ostatní se postará SCEF. Pokud je zařízení v režimu úspory energie PSM nebo eDRX, budou data bufferována a doručena, jakmile se zařízení stane dostupným. Pokud je však zařízení dostupné pro trafik, data budou doručena okamžitě. Toto platí i pro řídicí příkazy.

V každém okamžiku může AS odvolat bufferovanou zprávu směrem k UE nebo ji nahradit novou.

Mechanismus bufferování může být také aplikován při přenosu MO-dat od UE směrem k AS. Pokud SCEF nemohl doručit data k AS okamžitě, například pokud probíhají servisní práce na serverech AS, tyto pakety budou bufferovány a zaručeně doručeny, jakmile bude AS dostupný.

Jak bylo zmíněno výše, přístup k určitému servisu a UE pro AS (a NIDD – to je servis) je regulován pravidly a politikami na straně SCEF, což umožňuje realizaci jedinečné možnosti současného použití dat jednoho UE několika AS. Tedy, pokud se několik AS přihlásilo k jednomu UE, pak po obdržení dat od UE SCEF tyto data rozesílá na všechny přihlášené AS. To je dobře vhodné pro případy, kdy tvůrce parku specializovaných zařízení sdílí data mezi několika klienty. Například, vytvořením sítě meteorologických stanic fungujících na NB-IoT lze prodávat data z nich mnoha službám současně.

Mechanismus zaručeného doručení zpráv

Reliable Data Service — mechanizmus zaručeného doručení MO a MT zpráv bez použití specializovaných algoritmů na protokolové úrovni, jako je například handshake v TCP. Funguje na základě zahrnutí zvláštního příznaku do řídicí části zprávy při výměně mezi UE a SCEF. Aktivaci nebo deaktivaci tohoto mechanizmu při přenosu dat rozhoduje AS.

Pokud je mechanizmus aktivován, UE při potřebě zaručeného doručení MO dat zahrnuje zvláštní příznak do řídicí části paketu. Při obdržení takového paketu SCEF odpovídá UE potvrzením. Pokud UE neobdržela paket s potvrzením, paket směrem k SCEF bude znovu odeslán. To samé platí i pro MT data.

Monitorování zařízení (monitoring events- MONTE)

Jak bylo uvedeno výše, funkcionalita SCEF, mimo jiné, zahrnuje funkce kontroly stavu UE, tzv. monitorování zařízení. A pokud jsou nové identifikátory a mechanizmy přenosu dat optimalizace (i když velmi závažné) již existujících postupů, MONTE je zcela nová funkcionalita, která není dostupná v sítích 2G/3G/LTE. MONTE umožňuje AS sledovat takové parametry zařízení, jako je stav připojení, dostupnost pro komunikaci, poloha, roamingový status atd. O každém z nich se dozvíte podrobněji později.

Pokud je třeba aktivovat jakoukoli událost monitorování pro zařízení nebo skupinu zařízení, AS se přihlásí k odpovídající službě zasláním příkazu příslušného API MONTE na SCEF, který zahrnuje takové parametry, jako je external Id nebo external group ID, identifikátor AS, typ monitorování, počet reportů, které AS chce obdržet. Pokud je AS autorizován k provedení dotazu, SCEF podle typu provizuje událost na HSS nebo MME. Při vzniku události MME nebo HSS generují report směrem k SCEF, který ho pak odešle na AS.

Provizionování všech událostí, kromě „Počet UEs přítomných v geografické oblasti“, probíhá prostřednictvím HSS. Dvě události „Change of IMSI-IMEI Association“ a „Roaming Status“ — se sledují přímo na HSS, ostatní HSS provizuje na MME.
Události mohou být jak jednorázové, tak periodické, a jsou určeny jejich typem.

Odeslání zprávy o události (reporting) probíhá uzlem, který sleduje událost, přímo na SCEF (obr. 5).

Důležitý bod: události sledování se mohou vztahovat jak na non-IP zařízení připojená přes SCEF, tak na IP zařízení, která předávají data klasickým způsobem přes MME-SGW-PGW.

Podívejme se podrobněji na každou z událostí sledování:

Ztráta konektivity — informuje AS, že UE již není dostupná pro data ani pro signalizační výměnu. K této události dojde, když na MME vyprší "mobile reachability timer" pro UE. V žádosti o tento typ sledování může AS uvést svou hodnotu "Maximum Detection Time" — pokud během této doby UE neprojeví žádnou aktivitu, AS bude informována, že UE není dostupná, včetně uvedení důvodu. K události také dojde, pokud byla UE z nějakého důvodu násilně odejmuta z sítě.

* Aby síť věděla, že zařízení je stále dostupné, pravidelně zahajuje proceduru aktualizace — Tracking Area Update (TAU). Frekvence této procedury je nastavena sítí pomocí časovače T3412 nebo (T3412_extended v případě PSM), jehož hodnota je předána zařízení během procedury Attach nebo při dalším TAU. Mobile reachability timer je obvykle o několik minut delší než T3412. Pokud UE před vypršením "Mobile reachability timer" neprovádí TAU, síť ji považuje za nedostupnou.

Dostupnost UE – Ukazuje, kdy se UE stává dostupnou pro DL provoz nebo SMS. K tomu dochází, když se UE stává dostupnou pro paging (pro UE v režimu eDRX) nebo když UE přechází do režimu ECM-CONNECTED (pro UE v režimu PSM nebo eDRX), tj. provádí TAU nebo odesílá uplink paket.

Zprávy o poloze – Tento typ sledovacích událostí umožňuje AS požádat o údaje o poloze UE. Může být požadována buď aktuální poloha (Current Location), nebo posledně známá (Last Known Location, určuje se na základě cell ID, ze kterého zařízení posledně provedlo TAU nebo předávalo provoz), což je relevantní pro zařízení nacházející se v režimu úspory energie PSM nebo eDRX. Pro "Current Location" může AS požadovat opakované zprávy, kdy MME bude AS informovat pokaždé, když dojde ke změně polohy zařízení.

Změna asociace IMSI-IMEI – Při aktivaci této události SCEF začíná sledovat změny v vazbě IMSI (identifikátor SIM karty) a IMEI (identifikátor zařízení). Při výskytu události informuje AS. Může být použit pro automatické přiřazení externího ID k zařízení během plánovaných prací na výměně, nebo sloužit jako identifikátor krádeže zařízení.

Stav Roamingu – Tento typ sledování se používá AS k určení, zda se UE nachází v domácí síti, nebo v síti roamingového partnera. Nepovinně může být předán PLMN (Veřejná mobilní síť) operátora, ve kterém je zařízení registrováno.

Chyba komunikace — Tento typ sledování informuje AS o výpadcích v komunikaci se zařízením, založené na příčinách přerušení spojení (release cause code) získaných ze sítě radiového přístupu (protokol S1-AP). Tato událost může pomoci určit, proč došlo k výpadku komunikace — z důvodu problémů na síti, například při přetížení eNodeb (Radio resources not available), nebo z důvodu selhání samotného zařízení (Radio Connection With UE Lost).

Dostupnost po DDN chybě – Tato událost informuje AS, že zařízení je dostupné po selhání komunikace. Může být použita, když je třeba předat data zařízení, ale předchozí pokus byl neúspěšný, protože UE nereagovalo na notifikaci od sítě (paging) a data nebyla doručena. Pokud byl tento typ sledování požadován pro UE, pak jakmile zařízení zahájí příchozí komunikaci, provede TAU nebo odešle data v uplinku, AS bude informován, že zařízení je dostupné. Procedura DDN (downlink data notification) funguje mezi MME a S/P-GW, takže tento typ sledování je dostupný pouze pro IP zařízení.

Stav připojení PDN – Informuje AS o změně stavu zařízení (stav připojení PDN) — připojení (aktivace PDN) nebo odpojení (odebrání PDN). To může být použito AS k iniciaci komunikace s UE, nebo naopak, k pochopení, že komunikace již není možná. Tento typ sledování je dostupný pro IP i non-IP zařízení.

Počet UE v geografické oblasti – Tento typ sledování se používá AS k určení počtu UE v určité geografické oblasti.

Spouštění zařízení (Device triggering)

V sítích 2G/3G byl proces registrace do sítě dvoustupňový: nejprve se zařízení registrovalo v SGSN (proces attach), a poté, pokud bylo potřeba přenášet data, se aktivoval PDP kontext – spojení s paketovou bránou (GGSN). V sítích 3G tyto dvě procedury probíhaly sekvenčně, t.j. zařízení nečekalo na okamžik, kdy mělo přenášet data, ale aktivovalo PDP ihned po dokončení procedury attach. V LTE byly tyto dvě procedury sloučeny do jedné, což znamená, že při attach zařízení ihned požadovalo aktivaci PDN connection (analog PDP v 2G/3G) přes eNodeB k MME-SGW-PGW.

V NB-IoT je definován způsob připojení „attach without PDN“, což znamená, že UE provádí attach, aniž by vytvořilo PDN spojení. V tomto případě není dostupné pro přenos provozu a může pouze přijímat nebo odesílat SMS. Aby bylo možné na takové zařízení poslat příkaz k aktivaci PDN a připojení k AS, byla vyvinuta funkčnost „Device triggering”.

Při obdržení příkazu na připojení takového UE od AS, SCEF prostřednictvím SMS centra iniciuje odeslání řídící SMS na zařízení. Po obdržení SMS zařízení aktivuje PDN a připojuje se k AS pro další pokyny nebo přenos dat.

Může nastat situace, kdy na SCEF vyprší předplatné na zařízení. Ano, předplatné má svou dobu platnosti, stanovenou operátorem nebo dohodnutou s AS. Po jeho vypršení dojde na MME k deaktivační PDN a zařízení se stane nedostupným pro AS. V tomto případě také pomůže funkčnost „Device triggering”. Při obdržení nových dat od AS SCEF zjistí stav připojení zařízení a doručí data prostřednictvím SMS kanálu.

Závěr

Funkčnost SCEF se samozřejmě neomezuje na výše popsané služby a neustále evoluuje a rozšiřuje. V současné době je pro SCEF již standardizováno více než tucet služeb. Nyní jsme se dotkli pouze základních a žádaných funkcí ze strany vývojářů, o ostatních budeme hovořit v budoucích článcích.

Hned se nabízí otázka, jak získat testovací přístup k tomuto „zázračnému“ uzlu pro předběžné testování a ladění možných případů? Vše je velmi jednoduché. Jakýkoli vývojář může poslat žádost na iot.info@mts.ru, v níž stačí uvést účel připojení, popis možného případu a kontaktní údaje pro spojení.

Na shledanou!

Autoři:

• senior expert in convergent solutions and multimedia services Sergey Novikov sanov,
• expert in convergent solutions and multimedia services Alexey Lapshin aslapsh

Zdroj: habr.com