NB-IoT: jak to funguje? Část 3: SCEF – jediné okno přístupu ke službám operátora

V článku „NB-IoT: jak to funguje? Část 2“, když jsme hovořili o architektuře paketového jádra sítě NB-IoT, zmínili jsme vzhled nového uzlu SCEF. Vysvětlíme ve třetí části, co to je a proč je to potřeba?

Při vytváření služby M2M čelí vývojáři aplikací následujícím otázkám:

• jak identifikovat zařízení;
• jaký ověřovací a autentizační algoritmus použít;
• jaký přenosový protokol zvolit pro interakci se zařízeními;
• jak spolehlivě doručit data do zařízení;
• jak organizovat a stanovit pravidla pro výměnu dat s nimi;
• jak sledovat a získávat informace o jejich stavu online;
• jak současně doručovat data do skupiny vašich zařízení;
• jak současně odesílat data z jednoho zařízení několika klientům;
• jak získat jednotný přístup k dalším službám operátora pro správu vašeho zařízení.

K jejich řešení je nutné vytvořit proprietární technicky „těžká“ řešení, což vede ke zvýšeným mzdovým nákladům a časo- vým uvedením služeb na trh. Zde přichází na pomoc nový uzel SCEF.

Jak je definováno 3GPP, SCEF (funkce odhalení schopností služeb) je zcela novou součástí architektury 3GPP, jejíž funkcí je bezpečně odhalit služby a schopnosti poskytované síťovými rozhraními 3GPP prostřednictvím rozhraní API.

Jednoduše řečeno, SCEF je prostředníkem mezi sítí a aplikačním serverem (AS), jediné okno přístupu ke službám operátora pro správu vašeho zařízení M2M v síti NB-IoT prostřednictvím intuitivního standardizovaného rozhraní API.

SCEF skrývá složitost sítě operátora a umožňuje vývojářům aplikací abstrahovat složité mechanismy pro interakci se zařízeními specifické pro zařízení.

Transformací síťových protokolů na známé API pro vývojáře aplikací SCEF API usnadňuje vytváření nových služeb a zkracuje dobu uvedení na trh. Nový uzel také obsahuje funkce pro identifikaci/autentizaci mobilních zařízení, definování pravidel pro výměnu dat mezi zařízením a AS, odstranění nutnosti implementace těchto funkcí pro vývojáře aplikací na jejich straně, přesun těchto funkcí na bedra operátora.

SCEF pokrývá rozhraní nezbytná 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 možnosti sítě operátora.

Směrem k AS je jediné rozhraní T8, API (HTTP/JSON) standardizované 3GPP. Všechna rozhraní, s výjimkou T8, pracují na základě protokolu DIAMETER (obr. 1).

T6a – rozhraní mezi SCEF a MME. Používá se pro procedury řízení mobility/relací, přenos non-IP dat, poskytování monitorovacích událostí a přijímání zpráv o nich.

S6t – rozhraní mezi SCEF a HSS. Vyžaduje se pro autentizaci předplatitele, autorizaci aplikačních serverů, získání kombinace externího ID a IMSI/MSISDN, zřizování monitorovacích událostí a přijímání zpráv o nich.

S6m/T4 – rozhraní z SCEF na HSS a SMS-C (3GPP definuje uzel MTC-IWF, který se používá pro spouštění zařízení a přenos SMS v sítích NB-IoT. Ve všech implementacích je však funkčnost tohoto uzlu integrována do SCEF, takže pro zjednodušení obvodu jej nebudeme uvažovat samostatně). Slouží k získání informací o směrování pro odesílání SMS a interakci s SMS centrem.

T8 – API rozhraní pro interakci SCEF s aplikačními servery. Přes toto rozhraní jsou přenášeny jak řídicí příkazy, tak provoz.

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

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

• propojení identifikátoru SIM karty (IMSI) s externím ID;
• přenos non-IP provozu (Non-IP Data Delivery, NIDD);
• skupinové operace pomocí externího ID skupiny;
• podpora režimu přenosu dat s potvrzením;
• ukládání dat MO (Mobile Originated) a MT (Mobile Terminated);
• ověřování a autorizace zařízení a aplikačních serverů;
• současné použití dat z jednoho UE několika AS;
• podpora speciálních funkcí monitorování stavu UE (MONTE – Monitoring Events);
• spouštění zařízení;
• poskytování non-IP datového roamingu.

Základní princip interakce mezi AS a SCEF je založen na tzv. schématu. předplatné. Pokud je nutné získat přístup k jakékoli službě SCEF pro konkrétní UE, aplikační server potřebuje vytvořit předplatné zasláním příkazu do specifického API požadované služby a přijmout jako odpověď jedinečný identifikátor. Poté budou všechny další akce a komunikace s UE v rámci této služby probíhat pomocí tohoto identifikátoru.

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

Jednou z nejdůležitějších změn ve schématu interakce mezi AS a zařízeními při práci přes SCEF je vzhled univerzálního identifikátoru. Nyní se namísto telefonního čísla (MSISDN) nebo IP adresy, jako tomu bylo v klasické síti 2G/3G/LTE, z identifikátoru zařízení pro aplikační server stává „externí ID“. Je definován standardem ve formátu známém vývojářům aplikací “ @ "

Vývojáři již nemusí implementovat algoritmy ověřování zařízení, tuto funkci zcela přebírá síť. Externí ID je vázáno na IMSI a vývojář si může být jistý, že při přístupu ke konkrétnímu externímu ID interaguje s konkrétní SIM kartou. Při použití SIM čipu získáte zcela unikátní situaci, kdy externí ID jednoznačně identifikuje konkrétní zařízení!

K jedné IMSI lze navíc připojit několik externích ID – ještě zajímavější situace nastane, když externí ID jednoznačně identifikuje konkrétní aplikaci zodpovědnou za konkrétní službu na konkrétním zařízení.

Objeví se také identifikátor skupiny – externí ID skupiny, které zahrnuje sadu jednotlivých externích ID. Nyní může AS s jedním požadavkem na SCEF iniciovat skupinové operace – odesílání dat nebo řídicích příkazů do více zařízení sdružených do jediné logické skupiny.

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

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

V NB-IoT se v rámci optimalizace mechanismů pro přenos malého množství dat vedle již existujících typů PDN, jako jsou IPv4, IPv6 a IPv4v6, objevil další typ - non-IP. V tomto případě zařízení (UE) nemá přidělenu IP adresu a data jsou přenášena bez použití IP protokolu. Provoz pro taková spojení je možné směrovat dvěma způsoby: klasicky - MME -> SGW -> PGW a následně PtP tunelem do AS (obr. 2) nebo pomocí SCEF (obr. 3).

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

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


Doručování MT provozu do zařízení prostřednictvím externího ID

Pro odeslání zprávy na klasické IP zařízení musí AS znát jeho IP adresu. Zde nastává problém: protože zařízení obvykle při registraci obdrží „šedou“ IP adresu, komunikuje s aplikačním serverem, který je umístěn na internetu, prostřednictvím NAT uzlu, kde je šedá adresa přeložena do bílé. Kombinace šedé a bílé IP adresy trvá omezenou dobu v závislosti na nastavení NAT. V průměru pro TCP nebo UDP - ne více než pět minut. To znamená, že pokud do 5 minut nedojde k výměně dat s tímto zařízením, spojení se rozpadne a zařízení již nebude dostupné na bílé adrese, se kterou byla zahájena relace s AS. Existuje několik řešení:

1. Použijte srdeční tep. Jakmile je spojení navázáno, zařízení si musí každých několik minut vyměňovat pakety s AS, čímž se zabrání uzavření překladů NAT. O nějaké energetické účinnosti zde ale nemůže být řeč.

2. Pokaždé, pokud je to nutné, zkontrolujte dostupnost balíčků pro zařízení na AS - pošlete zprávu na uplink.

3. Vytvořte privátní APN (VRF), kde budou aplikační server a zařízení ve stejné podsíti, a přiřaďte zařízením statické IP adresy. Bude to fungovat, ale je to téměř nemožné, když se bavíme o flotile tisíců, desetitisíců zařízení.

4. Nakonec nejvhodnější varianta: použít IPv6, nevyžaduje NAT, protože IPv6 adresy jsou přímo dostupné z internetu. I v tomto případě však při opětovné registraci zařízení obdrží novou IPv6 adresu a již nebude přístupné pomocí předchozí.

V souladu s tím je nutné odeslat na server nějaký inicializační paket s identifikátorem zařízení, aby bylo možné nahlásit novou IP adresu zařízení. Poté počkejte na potvrzovací paket od AS, který také ovlivňuje energetickou účinnost.

Tyto metody fungují dobře pro zařízení 2G/3G/LTE, kde zařízení nemá přísné požadavky na autonomii a v důsledku toho neexistují žádná omezení vysílacího času a provozu. Tyto metody nejsou vhodné pro NB-IoT z důvodu vysoké energetické náročnosti.

SCEF řeší tento problém: protože jediným identifikátorem zařízení pro AS je externí ID, AS potřebuje pouze odeslat datový paket do SCEF pro konkrétní externí ID a SCEF se postará o zbytek. V případě, že je zařízení v úsporném režimu PSM nebo eDRX, budou data ukládána do vyrovnávací paměti a dodána, jakmile bude zařízení k dispozici. Pokud je zařízení dostupné pro provoz, data budou doručena okamžitě. Totéž platí pro manažerské týmy.

AS může kdykoli vyvolat zprávu uloženou ve vyrovnávací paměti do UE nebo ji nahradit novou.

Mechanismus ukládání do vyrovnávací paměti může být také použit při vysílání MO dat z UE do AS. Pokud SCEF nebyl schopen doručit data do AS okamžitě, například pokud probíhá údržba na AS serverech, budou tyto pakety uloženy do vyrovnávací paměti a bude zaručeno, že budou doručeny, jakmile bude AS dostupný.

Jak bylo uvedeno výše, přístup ke konkrétní službě a UE pro AS (a NIDD je služba) je regulován pravidly a politikami na straně SCEF, což umožňuje jedinečnou možnost současného použití dat z jednoho UE několika AS. Tito. pokud se několik AS přihlásilo k jednomu UE, pak po přijetí dat z UE je SCEF pošle všem přihlášeným AS. To se dobře hodí pro případy, kdy tvůrce flotily specializovaných zařízení sdílí data mezi několika klienty. Například vytvořením sítě meteostanic běžících na NB-IoT můžete data z nich prodávat mnoha službám současně.

Garantovaný mechanismus doručování zpráv

Reliable Data Service je mechanismus pro garantované doručování zpráv MO a MT bez použití specializovaných algoritmů na úrovni protokolu, jako je například handshake v TCP. Funguje tak, že při výměně mezi UE a SCEF zahrne speciální příznak do servisní části zprávy. O tom, zda aktivovat tento mechanismus při přenosu provozu, rozhoduje AS.

Pokud je mechanismus aktivován, UE zahrnuje speciální příznak v režijní části paketu, když vyžaduje zaručené doručení MO provozu. Po přijetí takového paketu SCEF odpoví UE potvrzením. Pokud UE nepřijme potvrzovací paket, paket směrem k SCEF bude znovu odeslán. Totéž se děje pro provoz MT.

Monitorování zařízení (monitorování událostí – MONTE)

Jak bylo uvedeno výše, funkcionalita SCEF mimo jiné obsahuje funkce pro sledování stavu UE, tzv. monitorování zařízení. A pokud jsou nové identifikátory a mechanismy přenosu dat optimalizací (byť velmi závažnou) stávajících postupů, pak je MONTE zcela novou funkcionalitou, která není dostupná v sítích 2G/3G/LTE. MONTE umožňuje AS sledovat parametry zařízení, jako je stav připojení, dostupnost komunikace, umístění, stav roamingu atd. O každém si povíme podrobněji o něco později.

Pokud je nutné aktivovat jakoukoli monitorovací událost pro zařízení nebo skupinu zařízení, AS se přihlásí k odběru odpovídající služby odesláním odpovídajícího API MONTE příkazu do SCEF, který obsahuje parametry jako externí Id nebo externí ID skupiny, AS identifikátor, monitorování typ, počet zpráv, které chce AS přijímat. Pokud je AS oprávněn provést požadavek, SCEF v závislosti na typu poskytne událost HSS nebo MME (obr. 4). Když dojde k události, MME nebo HSS vygeneruje zprávu do SCEF, která ji odešle do AS.

Poskytování všech událostí, s výjimkou „Počet UE přítomných v geografické oblasti“, probíhá prostřednictvím HSS. Dvě události „Změna asociace IMSI-IMEI“ a „Stav roamingu“ jsou sledovány přímo na HSS, zbytek bude zajišťovat HSS na MME.
Události mohou být jednorázové nebo periodické a jsou určeny svým typem.

Odeslání hlášení o události (reporting) provádí uzel, který událost sleduje přímo do SCEF (obr. 5).

Důležité místo: Monitorovací události lze aplikovat jak na non-IP zařízení připojená přes SCEF, tak na IP zařízení přenášející data klasickým způsobem přes MME-SGW-PGW.

Podívejme se blíže na každou z monitorovacích událostí:

Ztráta konektivity — informuje AS, že UE již není dostupné pro datový provoz ani pro signalizaci. K události dojde, když na MME vyprší „časovač mobilní dosažitelnosti“ pro UE. V požadavku na tento typ monitorování může AS indikovat svou hodnotu „Maximální čas detekce“ - pokud během této doby UE nevykazuje žádnou aktivitu, AS bude informováno, že UE je nedostupné, s uvedením důvodu. K této události také dochází, pokud bylo UE z jakéhokoli důvodu násilně odstraněno sítí.

* Aby síť věděla, že je zařízení stále dostupné, pravidelně zahajuje aktualizační proceduru – Tracking Area Update (TAU). Frekvenci této procedury nastavuje síť pomocí časovače T3412 nebo (T3412_extended v případě PSM), jehož hodnota je přenášena do zařízení během procedury Attach nebo další TAU. Časovač mobilní dostupnosti je obvykle o několik minut delší než T3412. Pokud UE neučiní TAU před vypršením „časovače mobilní dosažitelnosti“, síť jej považuje za již nedosažitelné.

dosažitelnost UE – Označuje, kdy bude UE dostupné pro provoz DL nebo SMS. K tomu dochází, když se UE stane dostupným pro stránkování (pro UE v režimu eDRX) nebo když UE vstoupí do režimu ECM-CONNECTED (pro UE v režimu PSM nebo eDRX), tj. vytvoří TAU nebo odešle uplinkový paket.

Hlášení polohy – Tento typ monitorovacích událostí umožňuje přidruženému systému dotazovat se na umístění UE. Lze vyžádat buď aktuální polohu (Aktuální poloha), nebo poslední známou polohu (Poslední známá poloha, určená podle ID buňky, ze které zařízení naposledy provedlo TAU nebo vysílalo provoz), což je relevantní pro zařízení s úsporou energie PSM nebo eDRX. režimy. Pro „Aktuální polohu“ může AS požadovat opakované odpovědi, přičemž MME informuje AS pokaždé, když se poloha zařízení změní.

Změna asociace IMSI-IMEI – Když je tato událost aktivována, SCEF začne sledovat změny v kombinaci IMSI (identifikátor SIM karty) a IMEI (identifikátor zařízení). Když dojde k události, informuje AS. Může být použit k automatickému opětovnému spojení externího ID se zařízením během plánované výměny nebo sloužit jako identifikátor pro krádež zařízení.

Stav roamingu – tento typ monitorování používá AS k určení, zda je UE v domovské síti nebo v síti roamingového partnera. Volitelně lze přenášet PLMN (Public Land Mobile Network) operátora, u kterého je zařízení registrováno.

Selhání komunikace — Tento typ monitorování informuje AS o poruchách komunikace se zařízením na základě příčin ztráty spojení (kód příčiny uvolnění) přijatých z rádiové přístupové sítě (protokol S1-AP). Tato událost může pomoci určit, proč komunikace selhala – kvůli problémům v síti, například když je eNodeb přetížený (rádiové zdroje nejsou k dispozici) nebo kvůli poruše samotného zařízení (Radio Connection With UE Lost).

Dostupnost po selhání DDN – tato událost informuje AS, že se zařízení stalo dostupným po selhání komunikace. Lze použít, když je potřeba přenést data do zařízení, ale předchozí pokus nebyl úspěšný, protože UE neodpovědělo na upozornění ze sítě (paging) a data nebyla doručena. Pokud byl tento typ monitorování požadován pro UE, pak jakmile zařízení provede příchozí komunikaci, vytvoří TAU nebo odešle data do uplinku, bude AS informován, že se zařízení stalo dostupným. Protože mezi MME a S/P-GW funguje postup DDN (downlink data notification), je tento typ monitorování dostupný pouze pro IP zařízení.

Stav připojení PDN – informuje AS o změně stavu zařízení (stav konektivity PDN) - připojení (aktivace PDN) nebo odpojení (smazání PDN). Toho může AS použít k zahájení komunikace s UE nebo naopak, aby pochopil, že komunikace již není možná. Tento typ monitorování je dostupný pro IP i non-IP zařízení.

Počet UE přítomných v geografické oblasti – Tento typ monitorování používá AS k určení počtu UE v určité geografické oblasti.

Spouštění zařízení)

V sítích 2G/3G byla procedura registrace v síti dvoufázová: nejprve se zařízení zaregistrovalo do SGSN (attach procedure), poté v případě potřeby aktivovalo PDP kontext - spojení s paketovou bránou (GGSN) přenášet data. V sítích 3G se tyto dva postupy vyskytovaly postupně, tzn. zařízení nečekalo na okamžik, kdy potřebovalo přenést data, ale aktivovalo PDP ihned po dokončení procedury připojení. V LTE byly tyto dva postupy spojeny do jednoho, to znamená, že při připojování si zařízení okamžitě vyžádalo aktivaci PDN spojení (obdoba PDP v 2G/3G) přes eNodeB do MME-SGW-PGW.

NB-IoT definuje metodu připojení jako „připojit bez PDN“, to znamená, že se UE připojí bez vytvoření připojení PDN. V tomto případě není k dispozici pro přenos provozu a může pouze přijímat nebo odesílat SMS. Aby bylo možné do takového zařízení odeslat příkaz k aktivaci PDN a připojení k AS, byla vyvinuta funkce „Spouštění zařízení“.

Při přijetí příkazu k připojení takového UE z AS, SCEF zahájí odesílání řídící SMS do zařízení přes SMS centrum. Při příjmu SMS zařízení aktivuje PDN a připojí se k AS za účelem přijetí dalších pokynů nebo přenosu dat.

Může nastat situace, kdy vaše předplatné zařízení na SCEF vyprší. Ano, předplatné má svou životnost, nastavenou operátorem nebo dohodnutou s AS. Po uplynutí platnosti bude PDN deaktivováno na MME a zařízení se stane nedostupným pro AS. V tomto případě pomůže také funkce „Spouštění zařízení“. Při příjmu nových dat z 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 pouze na výše popsané služby a neustále se vyvíjí a rozšiřuje. V současné době již bylo pro SCEF standardizováno více než tucet služeb. Nyní jsme se dotkli pouze hlavních funkcí, které jsou od vývojářů požadovány, o zbytku budeme hovořit v budoucích článcích.

Okamžitě vyvstává 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é. Žádost může podat každý vývojář [chráněno e-mailem], ve kterém stačí uvést účel připojení, popis možného případu a kontaktní údaje pro komunikaci.

Až do příště!

Autoři:

• senior expert oddělení konvergentních řešení a multimediálních služeb Sergey Novikov sanov,
• expert oddělení konvergentních řešení a multimediálních služeb Alexey Lapshin aslapsh

Zdroj: www.habr.com