Í greininni „“, þegar við töluðum um arkitektúr pakkakjarna NB-IoT netsins, minntum við á útlit nýs SCEF hnút. Við útskýrum í þriðja hluta hvað það er og hvers vegna það er þörf?
Þegar þú býrð til M2M þjónustu standa forritarar frammi fyrir eftirfarandi spurningum:
- hvernig á að bera kennsl á tæki;
- hvaða sannprófunar- og auðkenningaralgrím á að nota;
- hvaða flutningsreglur á að velja fyrir samskipti við tæki;
- hvernig á að afhenda gögn á áreiðanlegan hátt til tækja;
- hvernig á að skipuleggja og setja reglur um gagnaskipti við þá;
- hvernig á að fylgjast með og afla upplýsinga um ástand þeirra á netinu;
- hvernig á að afhenda gögn samtímis til hóps tækja þinna;
- hvernig á að senda gögn samtímis úr einu tæki til nokkurra viðskiptavina;
- hvernig á að fá samræmdan aðgang að viðbótarþjónustu símafyrirtækisins til að stjórna tækinu þínu.
Til að leysa þau er nauðsynlegt að búa til sértækar tæknilega „þungar“ lausnir, sem leiða til aukins launakostnaðar og tíma-til-markaðsþjónustu. Þetta er þar sem nýi SCEF hnúturinn kemur til bjargar.
Eins og skilgreint er af 3GPP, er SCEF (service capability exposure function) algjörlega nýr hluti af 3GPP arkitektúrnum sem hefur það hlutverk að afhjúpa á öruggan hátt þjónustuna og möguleikana sem 3GPP netviðmót veita í gegnum API.
Í einföldum orðum, SCEF er milliliður á milli netsins og forritaþjónsins (AS), einn aðgangsgluggi að rekstraraðilaþjónustu til að stjórna M2M tækinu þínu í NB-IoT netinu í gegnum leiðandi, staðlað API viðmót.
SCEF felur margbreytileika netkerfis rekstraraðila og gerir forriturum kleift að draga úr flóknum, tækjasértækum aðferðum til að hafa samskipti við tæki.
Með því að umbreyta netsamskiptareglum í kunnuglegt API fyrir forritara, auðveldar SCEF API sköpun nýrrar þjónustu og dregur úr tíma á markað. Nýi hnúturinn inniheldur einnig aðgerðir til að bera kennsl á/auðkenna farsíma, skilgreina reglur um gagnaskipti milli tækisins og AS, fjarlægja þörfina fyrir forritara til að innleiða þessar aðgerðir á hliðinni, færa þessar aðgerðir yfir á herðar stjórnandans.
SCEF nær yfir þau viðmót sem nauðsynleg eru til að auðkenna og veita leyfi fyrir forritaþjónum, viðhalda UE hreyfanleika, gagnaflutningi og ræsingu tækja, aðgang að viðbótarþjónustu og netgetu símafyrirtækis.
Í átt að AS er eitt T8 tengi, API (HTTP/JSON) staðlað af 3GPP. Öll tengi, að undanskildum T8, starfa á grundvelli DIAMETER samskiptareglunnar (mynd 1).
T6a – tengi milli SCEF og MME. Notað fyrir hreyfanleika/lotustjórnunarferli, sendingu á gögnum sem ekki eru IP, útvegun vöktunarviðburða og móttöku skýrslna um þá.
S6t – tengi milli SCEF og HSS. Nauðsynlegt fyrir auðkenningu áskrifenda, heimild fyrir forritaþjónum, til að fá blöndu af ytri auðkenni og IMSI/MSISDN, útvega vöktunarviðburði og fá skýrslur um þá.
S6m/T4 – tengi frá SCEF til HSS og SMS-C (3GPP skilgreinir MTC-IWF hnútinn, sem er notaður fyrir ræsingu tækja og SMS sendingu í NB-IoT netkerfum. Hins vegar er virkni þessa hnút samþætt í öllum útfærslum SCEF, svo til að einfalda hringrásina munum við ekki íhuga það sérstaklega). Notað til að fá leiðarupplýsingar til að senda SMS og hafa samskipti við SMS-miðstöðina.
T8 – API tengi fyrir SCEF samskipti við forritaþjóna. Bæði stjórnskipanir og umferð eru send í gegnum þetta viðmót.
*Í raun og veru eru fleiri viðmót; aðeins þau einföldustu eru skráð hér. Heildarlisti er gefinn í 3GPP 23.682 (4.3.2 Listi yfir viðmiðunarpunkta).
Hér að neðan eru helstu aðgerðir og þjónusta SCEF:
- að tengja auðkenni SIM-korts (IMSI) við ytra auðkenni;
- sending á umferð sem ekki er IP (Non-IP Data Delivery, NIDD);
- hópaðgerðir með ytri hópauðkenni;
- stuðningur við gagnaflutningsham með staðfestingu;
- biðminni á MO (Mobile Originated) og MT (Mobile Terminated) gögnum;
- auðkenning og heimild tækja og forritaþjóna;
- samtímis notkun gagna frá einni UE af nokkrum ASes;
- stuðningur við sérstakar UE stöðuvöktunaraðgerðir (MONTE – Vöktunarviðburðir);
- kveikja tækis;
- veita ekki IP gagnareiki.
Grunnreglan um samspil AS og SCEF byggist á svokölluðu kerfi. áskriftum. Ef nauðsynlegt er að fá aðgang að einhverri SCEF þjónustu fyrir tiltekið UE þarf forritaþjónninn að búa til áskrift með því að senda skipun á tiltekið API umbeðinnar þjónustu og fá einstakt auðkenni sem svar. Eftir það munu allar frekari aðgerðir og samskipti við UE innan ramma þessarar þjónustu fara fram með því að nota þetta auðkenni.
Ytra auðkenni: Alhliða auðkenni tækis
Ein mikilvægasta breytingin á samskiptakerfinu milli AS og tækja þegar unnið er í gegnum SCEF er útlit alhliða auðkennis. Nú, í stað símanúmers (MSISDN) eða IP-tölu, eins og var í hinu klassíska 2G/3G/LTE neti, verður auðkenni tækisins fyrir forritaþjóninn „ytra auðkenni“. Það er skilgreint af staðlinum á sniði sem forritarar þekkja " @ "
Hönnuðir þurfa ekki lengur að innleiða auðkenningaralgrím; netið tekur algjörlega yfir þessa aðgerð. Ytra auðkenni er bundið við IMSI og verktaki getur verið viss um að þegar hann opnar tiltekið ytra auðkenni hafi það samskipti við tiltekið SIM-kort. Þegar þú notar SIM-kubba færðu algjörlega einstaka aðstæður þegar ytra auðkenni auðkennir ákveðið tæki!
Þar að auki er hægt að tengja nokkur ytri auðkenni við eitt IMSI - enn áhugaverðari staða kemur upp þegar ytri auðkenni auðkennir á einkvæman hátt tiltekið forrit sem ber ábyrgð á tiltekinni þjónustu á tilteknu tæki.
Hópauðkenni birtist einnig - ytri hópauðkenni, sem inniheldur sett af einstökum ytri auðkennum. Nú, með einni beiðni til SCEF, getur AS hafið hópaðgerðir - sent gögn eða stjórnskipanir til margra tækja sameinuð í einum rökréttum hópi.
Vegna þess að fyrir AS þróunaraðila getur umskipti yfir í nýtt tækisauðkenni ekki verið samstundis, skildi SCEF eftir möguleika á AS-samskiptum við UE í gegnum staðlað númer - MSISDN.
Sending á umferð sem ekki er IP (Non-IP Data Delivery, NIDD)
Í NB-IoT, sem hluti af hagræðingu aðferða til að senda lítið magn af gögnum, til viðbótar við núverandi PDN gerðir, eins og IPv4, IPv6 og IPv4v6, hefur önnur tegund birst - ekki IP. Í þessu tilviki er tækinu (UE) ekki úthlutað IP tölu og gögn eru send án þess að nota IP samskiptareglur. Umferð um slíkar tengingar er hægt að beina á tvo vegu: klassískt - MME -> SGW -> PGW og síðan í gegnum PtP göngin til AS (Mynd 2) eða með því að nota SCEF (Mynd 3).
Klassíska aðferðin býður ekki upp á neina sérstaka kosti umfram IP-umferð, nema að minnka stærð sendra pakka vegna skorts á IP-hausum. Notkun SCEF opnar ýmsa nýja möguleika og einfaldar verulega verklag við samskipti við tæki.
Þegar gögn eru send í gegnum SCEF koma tveir mjög mikilvægir kostir fram yfir klassíska IP umferð:
Afhending MT umferðar í tækið með ytri auðkenni
Til að senda skilaboð í klassískt IP tæki verður AS að vita IP tölu þess. Hér kemur upp vandamál: þar sem tækið fær venjulega „grátt“ IP-tölu við skráningu, hefur það samskipti við forritaþjóninn, sem er staðsettur á netinu, í gegnum NAT-hnút, þar sem gráa vistfangið er þýtt yfir á hvítt. Samsetningin af gráum og hvítum IP tölum endist í takmarkaðan tíma, allt eftir NAT stillingum. Að meðaltali, fyrir TCP eða UDP - ekki meira en fimm mínútur. Það er, ef engin gagnaskipti eru með þetta tæki innan 5 mínútna mun tengingin slitna og tækið verður ekki lengur aðgengilegt á hvíta heimilisfanginu sem lotan með AS var hafin með. Það eru nokkrar lausnir:
1. Notaðu hjartslátt. Þegar tenging hefur verið komið á þarf tækið að skiptast á pökkum við AS á nokkurra mínútna fresti og koma þannig í veg fyrir að NAT þýðingar lokist. En hér má ekki tala um neina orkunýtingu.
2. Í hvert skipti, ef nauðsyn krefur, athugaðu hvort pakkar séu tiltækir fyrir tækið á AS - sendu skilaboð til upphleðslunnar.
3. Búðu til einka-APN (VRF), þar sem forritaþjónninn og tækin verða á sama undirneti og úthlutaðu kyrrstæðum IP-tölum til tækjanna. Það mun virka en það er nánast ómögulegt þegar við erum að tala um þúsunda, tugþúsundir tækjaflota.
4. Að lokum, heppilegasti kosturinn: notaðu IPv6, það þarf ekki NAT, þar sem IPv6 vistföng eru beint aðgengileg af internetinu. Hins vegar, jafnvel í þessu tilfelli, þegar tækið er endurskráð, mun það fá nýtt IPv6 vistfang og verður ekki lengur aðgengilegt með því að nota það fyrra.
Í samræmi við það er nauðsynlegt að senda einhvern frumstillingarpakka með auðkenni tækis til netþjónsins til að tilkynna um nýja IP tölu tækisins. Bíðið svo eftir staðfestingarpakka frá AS, sem hefur einnig áhrif á orkunýtingu.
Þessar aðferðir virka vel fyrir 2G/3G/LTE tæki, þar sem tækið gerir ekki strangar kröfur um sjálfræði og þar af leiðandi eru engar takmarkanir á útsendingartíma og umferð. Þessar aðferðir henta ekki fyrir NB-IoT vegna mikillar orkunotkunar.
SCEF leysir þetta vandamál: þar sem eina tækjaauðkennið fyrir AS er ytra auðkenni þarf AS aðeins að senda gagnapakka til SCEF fyrir tiltekið ytra auðkenni og SCEF sér um afganginn. Ef tækið er í PSM eða eDRX orkusparnaðarham verða gögn sett í biðminni og afhent þegar tækið verður tiltækt. Ef tækið er tiltækt fyrir umferð verða gögnin afhent strax. Sama á við um stjórnendur.
Hvenær sem er getur AS innkallað biðminni skilaboðin til UE eða skipt út fyrir nýtt.
Einnig er hægt að nota biðminni þegar MO gögn eru send frá UE til AS. Ef SCEF gat ekki afhent gögn til AS-netsins strax, til dæmis ef viðhaldsvinna er í gangi á AS-þjónunum, verða þessir pakkar í biðminni og tryggt að þeir verði afhentir um leið og AS-kerfið verður tiltækt.
Eins og fram kemur hér að ofan er aðgangur að tiltekinni þjónustu og UE fyrir AS (og NIDD er þjónusta) stjórnað af reglum og stefnum á SCEF hliðinni, sem gerir ráð fyrir einstökum möguleika á samtímis notkun gagna frá einu UE af nokkrum ASes. Þeir. ef nokkur AS hafa gerst áskrifandi að einu UE, þá mun SCEF senda þau til allra AS sem eru áskrifendur eftir að hafa fengið gögn frá UE. Þetta hentar vel fyrir tilvik þar sem skapari flota sérhæfðra tækja deilir gögnum á milli nokkurra viðskiptavina. Til dæmis, með því að búa til net veðurstöðva sem keyra á NB-IoT, geturðu selt gögn frá þeim til margra þjónustu samtímis.
Ábyrgð skilaboðasendingarkerfi
Áreiðanleg gagnaþjónusta er kerfi til að tryggja afhendingu MO og MT skilaboða án þess að nota sérhæfða reiknirit á samskiptareglum, eins og til dæmis handabandi í TCP. Það virkar með því að setja sérstakan fána í þjónustuhluta skilaboðanna þegar skipt er á milli UE og SCEF. Hvort á að virkja þetta kerfi þegar þú sendir umferð er ákveðið af AS.
Ef vélbúnaðurinn er virkjaður, inniheldur UE sérstakt fána í kostnaðarhluta pakkans þegar það krefst tryggrar afhendingu MO umferðar. Við móttöku slíks pakka, svarar SCEF UE með staðfestingu. Ef UE fær ekki staðfestingarpakkann, verður pakkinn til SCEF endursendur. Það sama gerist fyrir MT umferð.
Tækjavöktun (eftirlit með atburðum - MONTE)
Eins og getið er hér að ofan, felur SCEF virkni meðal annars í sér aðgerðir til að fylgjast með ástandi UE, svokallaða. eftirlit með tækjum. Og ef ný auðkenni og gagnaflutningsaðferðir eru hagræðingar (þó mjög alvarlegar) á núverandi verklagsreglum, þá er MONTE algjörlega ný virkni sem er ekki fáanleg í 2G/3G/LTE netum. MONTE gerir AS kleift að fylgjast með breytum tækisins eins og stöðu tengingar, framboð á samskiptum, staðsetningu, reikistöðu osfrv. Við munum tala um hvert og eitt nánar aðeins síðar.
Ef nauðsynlegt er að virkja einhverja vöktunaratburð fyrir tæki eða hóp tækja, gerist AS áskrifandi að samsvarandi þjónustu með því að senda samsvarandi API MONTE skipun til SCEF, sem inniheldur færibreytur eins og ytra auðkenni eða ytra hópauðkenni, AS auðkenni, vöktun tegund, fjölda tilkynninga, sem AS vill fá. Ef AS hefur heimild til að framkvæma beiðnina mun SCEF, allt eftir tegund, útvega viðburðinn til HSS eða MME (mynd 4). Þegar atburður á sér stað, býr MME eða HSS til skýrslu til SCEF, sem sendir hana til AS.
Útvegun allra viðburða, að undanskildum „Fjöldi UE sem eru til staðar á landfræðilegu svæði“, fer fram í gegnum HSS. Tveir atburðir „Breyting á IMSI-IMEI samtökum“ og „Reikistaða“ eru rakin beint á HSS, restin verður útveguð af HSS á MME.
Viðburðir geta verið annaðhvort einskipti eða reglubundin og eru ákvörðuð af gerð þeirra.
Sending skýrslu um atburð (tilkynning) fer fram af hnútnum sem rekur atburðinn beint til SCEF (mynd 5).
Mikilvægt atriði: Hægt er að beita eftirlitsviðburðum á bæði tæki sem ekki eru IP tengd í gegnum SCEF og IP tæki sem senda gögn á klassískan hátt í gegnum MME-SGW-PGW.
Við skulum skoða nánar hvern vöktunarviðburði:
Tap á tengingu — upplýsir AS að UE sé ekki lengur tiltækt fyrir hvorki gagnaumferð né merkjasendingar. Atvikið á sér stað þegar „teljari fyrir farsímaaðgengi“ fyrir UE rennur út á MME. Í beiðni um þessa tegund vöktunar getur AS gefið til kynna „Hámarksuppgötvunartíma“ gildi sitt - ef á þessum tíma sýnir UE enga virkni, verður AS tilkynnt um að UE sé ekki tiltækt og gefur til kynna ástæðuna. Atvikið á sér einnig stað ef UE var fjarlægt með valdi af netinu af einhverjum ástæðum.
* Til að láta símkerfið vita að tækið sé enn tiltækt, byrjar það reglulega uppfærsluferli - Tracking Area Update (TAU). Tíðni þessarar aðferðar er stillt af símkerfinu með því að nota tímamæli T3412 eða (T3412_extended ef um PSM er að ræða), gildið sem er sent til tækisins meðan á tengingunni stendur eða næsta TAU. Tímamælir fyrir farsímaaðgengi er venjulega nokkrum mínútum lengri en T3412. Ef UE hefur ekki gert TAU áður en „Tímamælir fyrir farsímaaðgengi“ rennur út, telur netið að það sé ekki lengur hægt að ná í hann.
UE aðgengi - Gefur til kynna þegar UE verður tiltækt fyrir DL-umferð eða SMS. Þetta gerist þegar UE verður tiltækt fyrir boðskipti (fyrir UE í eDRX ham) eða þegar UE fer í ECM-CONNECTED ham (fyrir UE í PSM eða eDRX ham), þ.e. gerir TAU eða sendir uplink pakka.
Staðsetningartilkynning – Þessi tegund eftirlitsatburða gerir AS kleift að spyrjast fyrir um staðsetningu UE. Annaðhvort er hægt að biðja um núverandi staðsetningu (Núverandi staðsetning) eða síðasta þekkta staðsetningu (Ákvörðuð af auðkenni farsímans sem tækið gerði TAU frá eða sendi umferð síðast) sem á við fyrir tæki í PSM eða eDRX orkusparnaðarstillingum. Fyrir „Núverandi staðsetningu“ getur AS beðið um endurtekin svör þar sem MME upplýsir AS í hvert skipti sem staðsetning tækisins breytist.
Breyting á IMSI-IMEI samtökum - Þegar þessi atburður er virkjaður byrjar SCEF að fylgjast með breytingum á samsetningu IMSI (SIM kortaauðkennis) og IMEI (auðkenni tækis). Þegar atburður á sér stað, tilkynnir AS. Hægt að nota til að endurbinda ytra auðkenni sjálfkrafa við tæki við áætlaða skiptivinnu eða þjóna sem auðkenni fyrir þjófnað á tæki.
Staða reiki – þessa tegund af vöktun er notuð af AS til að ákvarða hvort UE sé í heimaneti eða í neti reikifélaga. Valfrjálst er hægt að senda PLMN (Public Land Mobile Network) símafyrirtækisins sem tækið er skráð hjá.
Samskiptabilun — Þessi tegund vöktunar upplýsir AS um bilanir í samskiptum við tækið, byggt á ástæðum fyrir tapi á tengingu (losunarorsök kóða) sem berast frá útvarpsaðgangsnetinu (S1-AP samskiptareglur). Þessi atburður getur hjálpað til við að ákvarða hvers vegna samskiptin mistókust - vegna vandamála á netinu, til dæmis þegar eNodeb er ofhlaðinn (útvarpsauðlindir ekki tiltækar) eða vegna bilunar í tækinu sjálfu (Radio Connection With UE Lost).
Framboð eftir DDN bilun – þetta tilvik lætur AS vita að tækið sé orðið tiltækt eftir samskiptabilun. Hægt að nota þegar þörf er á að flytja gögn yfir í tæki, en fyrri tilraun tókst ekki vegna þess að UE svaraði ekki tilkynningu frá netinu (símboð) og gögnin voru ekki afhent. Ef beðið hefur verið um þessa tegund af vöktun fyrir UE, þá um leið og tækið kemur á móts við samskipti, gerir TAU eða sendir gögn til upptengilsins, verður AS tilkynnt um að tækið sé orðið tiltækt. Þar sem DDN (downlink data notification) ferlið virkar á milli MME og S/P-GW, er þessi tegund eftirlits aðeins í boði fyrir IP tæki.
PDN-tengingarstaða – lætur AS vita þegar staða tækisins breytist (PDN-tengingarstaða) - tenging (PDN virkjun) eða aftenging (PDN eyðing). Þetta getur AS notað til að hefja samskipti við UE, eða öfugt, til að skilja að samskipti eru ekki lengur möguleg. Þessi tegund af vöktun er fáanleg fyrir IP og önnur tæki.
Fjöldi UE sem eru til staðar á landfræðilegu svæði – Þessi tegund eftirlits er notuð af AS til að ákvarða fjölda UE á ákveðnu landsvæði.
Tæki kveikir)
Í 2G/3G netkerfum var skráningarferlið á netinu í tveimur þrepum: í fyrsta lagi tækið skráð með SGSN (tengja aðferð), síðan, ef nauðsyn krefur, virkjaði það PDP samhengið - tenging við pakkagáttina (GGSN) að senda gögn. Í 3G netkerfum áttu þessar tvær aðgerðir sér stað í röð, þ.e. tækið beið ekki eftir því augnabliki þegar það þurfti að flytja gögn, heldur virkjaði PDP strax eftir að viðhengisferlinu var lokið. Í LTE voru þessar tvær aðferðir sameinaðar í eina, það er, þegar það var tengt, bað tækið strax um virkjun PDN tengingarinnar (samsíða PDP í 2G/3G) í gegnum eNodeB til MME-SGW-PGW.
NB-IoT skilgreinir tengingaraðferð sem „tengjast án PDN“, það er, UE tengist án þess að koma á PDN tengingu. Í þessu tilviki er það ekki í boði til að senda umferð og getur aðeins tekið á móti eða sent SMS. Til þess að senda skipun til slíks tækis um að virkja PDN og tengjast AS, var „Device triggering“ virkni þróað.
Þegar skipun berst um að tengja slíkt UE frá AS, byrjar SCEF að senda stjórn SMS til tækisins í gegnum SMS miðstöðina. Þegar þú færð SMS virkjar tækið PDN og tengist AS til að fá frekari leiðbeiningar eða flytja gögn.
Það getur komið fyrir að tækisáskrift þín rennur út á SCEF. Já, áskriftin hefur sína eigin líftíma, stillt af rekstraraðila eða samið við AS. Þegar það rennur út verður PDN óvirkt á MME og tækið verður óaðgengilegt fyrir AS. Í þessu tilviki mun „Tækjaræsing“ virknin einnig hjálpa. Þegar ný gögn eru móttekin frá AS mun SCEF finna út stöðu tengingar tækisins og afhenda gögnin í gegnum SMS rás.
Ályktun
Virkni SCEF er auðvitað ekki takmörkuð við þá þjónustu sem lýst er hér að ofan og er í stöðugri þróun og stækkandi. Eins og er hefur meira en tugi þjónustu þegar verið staðlað fyrir SCEF. Nú höfum við aðeins snert helstu aðgerðir sem eru eftirsóttar frá hönnuðum; við munum tala um restina í framtíðargreinum.
Spurningin vaknar strax: hvernig á að fá prófunaraðgang að þessum „kraftaverka“ hnút fyrir bráðabirgðapróf og kembiforrit mögulegra mála? Allt er mjög einfalt. Allir verktaki getur lagt fram beiðni til [netvarið], þar sem nægir að tilgreina tilgang tengingar, lýsingu á hugsanlegu máli og tengiliðaupplýsingar vegna samskipta.
Þar til næst!
Höfundar:
- háttsettur sérfræðingur deildarinnar fyrir samrunalausnir og margmiðlunarþjónustu Sergey Novikov ,
- sérfræðingur í samrunalausnum og margmiðlunarþjónustudeild Alexey Lapshin
Heimild: www.habr.com