NB-IoT: Hur fungerar det? Del 3: SCEF – enda fönster för åtkomst till operatörstjänster

I artikeln "NB-IoT: hur fungerar det? Del 2", när vi pratade om arkitekturen för paketkärnan i NB-IoT-nätverket, nämnde vi framväxten av en ny SCEF-nod. I den tredje delen förklarar vi vad det är och varför det behövs?

När applikationsutvecklare skapar en M2M-tjänst står de inför följande frågor:

• hur man identifierar enheter;
• vilken algoritm som ska användas för verifiering och autentisering;
• vilket transportprotokoll som ska väljas för interaktion med enheter;
• hur man säkerställer att data levereras till enheter;
• hur man organiserar och upprättar regler för datautbyte med dem;
• hur man kontrollerar och får information om sitt tillstånd online;
• hur man levererar data till en grupp av sina enheter samtidigt;
• hur man skickar data från en enhet till flera klienter samtidigt;
• hur man får enhetlig åtkomst till ytterligare operatörstjänster för att hantera sin enhet.

För att lösa dem är det nödvändigt att skapa proprietära tekniskt "tunga" lösningar, vilket leder till en ökning av arbetskraftskostnader och time-to-market-tjänster. Det är här den nya SCEF-noden kommer till undsättning.

Enligt definitionen i 3GPP är SCEF (service capability exposure function) en helt ny komponent i 3GPP-arkitekturen vars funktion är att säkert exponera tjänster och funktioner som tillhandahålls av 3GPP-nätverksgränssnitt via API:er.

Enkelt uttryckt är SCEF en mellanhand mellan nätverket och applikationsservern (AS), ett enda fönster för åtkomst till operatörens tjänster för att hantera dess M2M-enhet i NB-IoT-nätverket via ett intuitivt standardiserat API-gränssnitt.

SCEF döljer komplexiteten i operatörens nätverk, vilket gör det möjligt för applikationsutvecklare att abstrahera bort de komplexa, enhetsspecifika interaktionsmekanismerna.

Genom att konvertera nätverksprotokoll till ett API-gränssnitt som är välbekant för applikationsutvecklare, underlättar SCEF skapandet av nya tjänster och minskar time-to-market. Den nya noden inkluderar även funktioner för att identifiera/autentisera mobila enheter, definiera regler för datautbyte mellan enheten och AS, vilket eliminerar behovet för applikationsutvecklare att implementera dessa funktioner på sin sida och flyttar dessa funktioner till operatören.

SCEF täcker de gränssnitt som krävs för autentisering och auktorisering av applikationsservrar, upprätthållande av UE-mobilitet, dataöverföring och enhetsaktivering, åtkomst till ytterligare tjänster och funktioner i operatörens nätverk.

Det finns bara ett gränssnitt T8, ett API-gränssnitt (HTTP/JSON), standardiserat av 3GPP, som går mot AS. Alla gränssnitt, utom T8, fungerar baserat på DIAMETER-protokollet (bild 1).

T6a – gränssnitt mellan SCEF och MME. Används för mobilitets-/sessionshanteringsprocedurer, icke-IP-dataöverföring, tillhandahållande av övervakningshändelser och mottagande av rapporter om dem.

S6t – gränssnitt mellan SCEF och HSS. Nödvändigt för prenumerantautentisering, auktorisering av applikationsserver, erhållande av externt ID och IMSI/MSISDN-bindning, provisionering av övervakningshändelser och mottagande av rapporter om dem.

S6m/T4 – gränssnitt från SCEF till HSS och SMS-C (3GPP definierar MTC-IWF-noden, som används för enhetsaktivering och SMS-överföring i NB-IoT-nätverk. I alla implementeringar är dock denna nods funktionalitet integrerad i SCEF, så för att förenkla schemat kommer vi inte att behandla den separat). De används för att ta emot routinginformation för att skicka SMS och interagera med SMS-centralen.

T8 är ett API-gränssnitt för SCEF-interaktion med applikationsservrar. Både kontrollkommandon och trafik överförs genom detta gränssnitt.

*i verkligheten finns det fler gränssnitt, endast de mest grundläggande listas här. Den fullständiga listan finns i 3GPP 23.682 (4.3.2 Lista över referenspunkter).

Nedan följer SCEF:s viktigaste funktioner och tjänster:

• länka SIM-kortsidentifieraren (IMSI) till det externa ID:t;
• överföring av icke-IP-trafik (Non-IP Data Delivery, NIDD);
• gruppoperationer med hjälp av externt grupp-ID;
• stöd för dataöverföringsläge med bekräftelse;
• buffring av MO (Mobile Originated) och MT (Mobile Terminated) data;
• autentisering och auktorisering av enheter och applikationsservrar;
• samtidig användning av data från en UE av flera AS;
• stöd för specialfunktioner för övervakning av UE-status (MONTE – Monitoring Events);
• enhetsutlösning;
• Tillhandahåller dataroaming utan IP-adress.

Grundprincipen för interaktion mellan AS och SCEF är baserad på det så kallade prenumerationsschemat. När åtkomst till en SCEF-tjänst krävs för en specifik UE, måste applikationsservern skapa en prenumeration genom att skicka ett kommando till ett specifikt API för den begärda tjänsten och få en unik identifierare som svar. Därefter kommer alla ytterligare åtgärder och kommunikationer med UE:n inom denna tjänst att utföras med hjälp av denna identifierare.

Externt ID: Universell enhetsidentifierare

En av de viktigaste förändringarna i schemat för interaktion mellan AS och enheter när de arbetar via SCEF är uppkomsten av en universell identifierare. Nu, istället för ett telefonnummer (MSISDN) eller IP-adress, som det var i det klassiska 2G/3G/LTE-nätverket, blir enhetsidentifieraren för applikationsservern "externt ID". Det definieras av standarden i det format som är bekant för applikationsutvecklare. @ ".

Utvecklare behöver inte längre implementera algoritmer för enhetsautentisering, nätverket tar över denna funktion helt och hållet. Externt ID är kopplat till IMSI, och utvecklaren kan vara säker på att när hen åtkommer ett specifikt externt ID interagerar hen med ett specifikt SIM-kort. När man använder ett SIM-chip uppstår en unik situation när det externa ID:t unikt identifierar en specifik enhet!

Dessutom kan flera externa ID:n kopplas till en IMSI – en ännu mer intressant situation uppstår när ett externt ID unikt identifierar en specifik applikation som ansvarar för en specifik tjänst på en specifik enhet.

En gruppidentifierare visas också – ett externt grupp-ID, som inkluderar en uppsättning individuella externa ID:n. Nu, med en begäran till SCEF, kan AS initiera gruppoperationer – skicka data eller kontrollkommandon till flera enheter som är sammanslagna till en enda logisk grupp.

På grund av att övergången till en ny enhetsidentifierare inte kan ske omedelbar för AS-utvecklare, lämnade SCEF möjligheten för AS-kommunikation med UE via ett standardnummer – MSISDN.

Icke-IP-dataleverans (NIDD)

I NB-IoT, som en del av optimeringen av mekanismerna för överföring av små mängder data, har, utöver de befintliga PDN-typerna som IPv4, IPv6 och IPv4v6, en annan typ dykt upp - icke-IP. I det här fallet tilldelas inte enheten (UE) en IP-adress, och data överförs utan att använda IP-protokollet. Trafik för sådana anslutningar kan dirigeras på två sätt: det klassiska sättet - MME -> SGW -> PGW och sedan genom en PtP-tunnel till AS (bild 2) eller med hjälp av SCEF (bild 3).

Den klassiska metoden har inga särskilda fördelar jämfört med IP-trafik, förutom minskningen av storleken på överförda paket på grund av avsaknaden av IP-headers. Användning av SCEF öppnar upp en hel rad nya möjligheter och förenklar avsevärt procedurerna för att interagera med enheter.

Vid överföring av data via SCEF uppstår två mycket viktiga fördelar jämfört med klassisk IP-trafik:


Leverans av MT-trafik till enheten via externt ID

För att skicka ett meddelande till en klassisk IP-enhet måste AS känna till dess IP-adress. Här uppstår ett problem: eftersom enheten vanligtvis får en "grå" IP-adress vid registrering kommunicerar den med applikationsservern, som finns på internet, via en NAT-nod, där den grå adressen översätts till en vit. Parningen av grå och vita IP-adresser varar under en begränsad tid, beroende på NAT-inställningarna. I genomsnitt, för TCP eller UDP, inte mer än fem minuter. Det vill säga, om det inte har skett något datautbyte med den här enheten på 5 minuter, kommer parningen att brytas och enheten kommer inte längre att vara tillgänglig på den vita adressen som sessionen med AS initierades med. Det finns flera lösningar:

1. Använd heartbeat. När en anslutning är upprättad måste enheten utbyta paket med AS:et med några minuters mellanrum, vilket förhindrar att översättningen på NAT:n avslutas. Men det kan inte bli tal om någon energieffektivitet här.

2. Varje gång det finns behov av att kontrollera om det finns paket för en enhet på AS:et, skicka ett meddelande till upplänken.

3. Skapa ett privat APN (VRF), där applikationsservern och enheterna kommer att finnas i samma subnät, och tilldela statiska IP-adresser till enheterna. Det kommer att fungera, men det är nästan omöjligt att implementera när vi pratar om en flotta på tusentals, tiotusentals enheter.

4. Slutligen, det lämpligaste alternativet: använd IPv6, det kräver inte NAT, eftersom IPv6-adresser är direkt tillgängliga från internet. Men även i det här fallet, när du registrerar om enheten, kommer den att få en ny IPv6-adress och kommer inte längre att vara tillgänglig via den tidigare.

Följaktligen är det nödvändigt att skicka ett initialiseringspaket med enhetsidentifieraren till servern för att rapportera enhetens nya IP-adress. Vänta sedan på ett bekräftelsepaket från AS, vilket också påverkar energieffektiviteten.

Dessa metoder fungerar bra för 2G/3G/LTE-enheter, där enheten inte har strikta krav på autonomi och det därför inte finns några begränsningar av tid i luften och trafik. Dessa metoder är inte lämpliga för NB-IoT på grund av deras höga energiförbrukning.

SCEF löser detta problem: eftersom den enda identifieraren för en enhet för ett AS är det externa ID:t, behöver AS bara skicka ett datapaket till SCEF för ett specifikt externt ID, och SCEF tar hand om resten. Om enheten är i PSM- eller eDRX-strömsparläge buffras data och levereras när enheten blir tillgänglig. Om enheten är tillgänglig för trafik levereras data omedelbart. Detsamma gäller för styrkommandon.

När som helst kan AS hämta det buffrade meddelandet till UE:n eller ersätta det med ett nytt.

Buffringsmekanismen kan också användas vid överföring av MO-data från UE:n till AS:en. Om SCEF:n inte kan leverera data till AS:en omedelbart, till exempel om underhållsarbete pågår på AS:ens servrar, kommer dessa paket att buffras och garanteras levereras så snart AS:en blir tillgänglig.

Som nämnts ovan regleras åtkomsten till en specifik tjänst och UE för ett AS (och NIDD är en tjänst) av regler och policyer på SCEF-sidan, vilket möjliggör implementering av en unik möjlighet för samtidig användning av data från en UE av flera AS. Det vill säga, om flera AS har prenumererat på en UE, kommer SCEF, efter att ha mottagit data från UE:n, att skicka den till alla prenumererande AS. Detta är väl lämpat i fall där skaparen av en flotta av specialiserade enheter delar data mellan flera klienter. Genom att till exempel skapa ett nätverk av väderstationer som drivs på NB-IoT kan man sälja data från dem till många tjänster samtidigt.

Garanterad meddelandeleveransmekanism

Tillförlitlig datatjänst (Reliable Data Service) är en mekanism för garanterad leverans av MO- och MT-meddelanden utan att använda specialiserade algoritmer på protokollnivå, såsom till exempel handskakning i TCP. Den fungerar genom att inkludera en speciell flagga i servicedelen av meddelandet under utbyte mellan UE och SCEF. AS avgör om denna mekanism ska aktiveras under trafiköverföring.

Om mekanismen aktiveras inkluderar UE:n en särskild flagga i servicedelen av paketet om den behöver garanterad leverans av MO-trafik. Vid mottagandet av ett sådant paket svarar SCEF UE:n med en bekräftelse. Om UE:n inte tar emot ett paket med en bekräftelse kommer paketet att skickas om till SCEF. Detsamma gäller för MT-trafik.

Övervakningsenheter (övervakning av händelser - MONTE)

Som nämnts ovan inkluderar SCEF-funktionaliteten bland annat UE-statuskontrollfunktioner, den så kallade enhetsövervakningen. Och om de nya identifierarna och dataöverföringsmekanismerna är optimeringar (om än mycket allvarliga) av befintliga procedurer, så är MONTE en helt ny funktionalitet som inte är tillgänglig i 2G/3G/LTE-nätverk. MONTE gör det möjligt för AS att spåra enhetsparametrar som anslutningsstatus, tillgänglighet för kommunikation, plats, roamingstatus etc. Vi kommer att prata om var och en mer detaljerat lite senare.

När det är nödvändigt att aktivera en övervakningshändelse för en enhet eller grupp av enheter, prenumererar AS på motsvarande tjänst genom att skicka ett kommando från motsvarande MONTE API till SCEF, vilket inkluderar parametrar som externt ID eller externt grupp-ID, AS-identifierare, övervakningstyp och antalet rapporter som AS vill ta emot. Om AS är behörig att utföra begäran kommer SCEF, beroende på typ, att vidarebefordra händelsen till HSS eller MME (Fig. 4). När en händelse inträffar genererar MME eller HSS en rapport till SCEF, som skickar den till AS.

Alla händelser utom "Antal UE:er närvarande i ett geografiskt område" hanteras via HSS. Två händelser, "Ändring av IMSI-IMEI-association" och "Roamingstatus", övervakas direkt på HSS, resten hanteras av HSS på MME.
Händelser kan vara antingen engångshändelser eller periodiska och bestäms av sin typ.

Händelserapporten skickas direkt till SCEF av noden som övervakar händelsen (bild 5).

Viktig punkt: Övervakningshändelser kan tillämpas på både icke-IP-enheter anslutna via SCEF och IP-enheter som överför data på klassiskt sätt via MME-SGW-PGW.

Låt oss titta närmare på var och en av övervakningshändelserna:

Förlust av anslutning — informerar AS att UE:n inte längre är tillgänglig för vare sig datatrafik eller signalering. Händelsen inträffar när "mobilåtkomlighetstimern" för UE:n löper ut på MME:n. I begäran om denna typ av övervakning kan AS ange sitt värde för "Maximal detektionstid" — om UE:n inte visar någon aktivitet under denna tid kommer AS att informeras om att UE:n inte är tillgänglig, med angivande av orsaken. Händelsen inträffar också om UE:n av någon anledning med våld har tagits bort av nätverket.

* För att nätverket ska veta att enheten fortfarande är tillgänglig initierar det regelbundet uppdateringsproceduren - Tracking Area Update (TAU). Frekvensen för denna procedur ställs in av nätverket med hjälp av T3412-timern eller (T3412_extended vid PSM), vars värde överförs till enheten under anslutningsproceduren eller nästa TAU. Timern för mobil nåbarhet är vanligtvis flera minuter längre än T3412. Om UE:n inte har skapat en TAU innan "Mobil nåbarhetstimern" löper ut, anser nätverket att den inte längre är tillgänglig.

UE-nåbarhet – Indikerar när UE:n blir tillgänglig för DL-trafik eller SMS. Detta inträffar när UE:n blir tillgänglig för personsökning (för UE:er i eDRX-läge) eller när UE:n går in i ECM-CONNECTED-läge (för UE:er i PSM- eller eDRX-läge), d.v.s. gör en TAU eller skickar ett upplänkspaket.

Platsrapportering – Denna typ av övervakningshändelser gör det möjligt för AS att begära data om UE:s plats. Antingen den aktuella platsen (Aktuell plats) eller den senast kända platsen (Senast känd plats, bestämd av cell-ID:t från vilken enheten gjorde en TAU eller överförde trafik senast) kan begäras, vilket är relevant för enheter i PSM- eller eDRX-strömsparlägen. För "Aktuell plats" kan AS begära upprepade rapporter, och MME informerar AS varje gång enhetens plats ändras.

Ändring av IMSI-IMEI-association – När denna händelse aktiveras börjar SCEF spåra ändringar i parkopplingen mellan IMSI (SIM-kortsidentifierare) och IMEI (enhetsidentifierare). När händelsen inträffar informerar den AS. Den kan användas för att automatiskt återkoppla det externa ID:t till enheten under schemalagt utbytesarbete eller fungera som en enhetsstöldidentifierare.

Roamingstatus – denna typ av övervakning används av AS för att avgöra om UE:n befinner sig i hemnätet eller i en roamingpartners nätverk. Alternativt kan PLMN (Public Land Mobile Network) från den operatör där enheten är registrerad överföras.

Kommunikationsfel — Denna typ av övervakning informerar AS om fel i kommunikationen med enheten, baserat på orsakerna till anslutningsfelet (release case code) som tas emot från radioåtkomstnätet (S1-AP-protokollet). Denna händelse kan hjälpa till att fastställa orsaken till kommunikationsfelet — på grund av nätverksproblem, såsom eNodeb-överbelastning (radioresurser inte tillgängliga) eller på grund av ett fel i själva enheten (radioanslutning med UE förlorad).

Tillgänglighet efter DDN-fel – denna händelse informerar AS om att enheten har blivit tillgänglig efter ett kommunikationsfel. Den kan användas när det är nödvändigt att överföra data till enheten, men det föregående försöket misslyckades, eftersom UE:n inte svarade på meddelandet från nätverket (personsökning), och data inte levererades. Om denna typ av övervakning begärdes för UE:n, kommer AS att informeras om att enheten har blivit tillgänglig så snart enheten gör en inkommande kommunikation, gör en TAU eller skickar data till upplänken. Eftersom DDN-proceduren (downlink data notification) fungerar mellan MME och S/P-GW, är denna typ av övervakning endast tillgänglig för IP-enheter.

PDN-anslutningsstatus – informerar AS när enhetens status (PDN-anslutningsstatus) ändras — anslutning (PDN-aktivering) eller frånkoppling (PDN-borttagning). Detta kan användas av AS för att initiera kommunikation med UE:n, eller vice versa, för att förstå att kommunikation inte längre är möjlig. Denna typ av övervakning är tillgänglig för IP- och icke-IP-enheter.

Antal UE:er som finns i ett geografiskt område – denna typ av övervakning används av AS för att fastställa antalet UE:er i ett visst geografiskt område.

Enhetsutlösning)

I 2G/3G-nätverk var registreringsproceduren i nätverket tvåstegs: först registrerades enheten i SGSN (anslutningsproceduren), sedan, när det var nödvändigt att överföra data, aktiverade den PDP-kontexten – anslutningen till paketgatewayen (GGSN). I 3G-nätverk var dessa två procedurer sekventiella, d.v.s. enheten väntade inte på det ögonblick då det var nödvändigt att överföra data, utan aktiverade PDP:n omedelbart efter att anslutningsproceduren hade slutförts. I LTE kombinerades dessa två procedurer till en, d.v.s. vid anslutning begärde enheten omedelbart aktivering av PDN-anslutningen (analogt med PDP i 2G/3G) via eNodeB till MME-SGW-PGW.

I NB-IoT definieras en anslutningsmetod som kallas "anslut utan PDN", d.v.s. UE:n ansluter utan att upprätta en PDN-anslutning. I det här fallet är den inte tillgänglig för trafiköverföring och kan bara ta emot eller skicka SMS. För att kunna skicka ett kommando till en sådan enhet för att aktivera PDN:n och ansluta till AS:et, utvecklades funktionen "Enhetsutlösning".

När SCEF tar emot ett kommando från AS att ansluta en sådan UE, initierar den ett kontroll-SMS till enheten via SMS-centret. När SMS:et tas emot aktiverar enheten PDN och ansluter till AS för att ta emot efterföljande instruktioner eller överföra data.

Det kan finnas fall då prenumerationen för en enhet löper ut på SCEF. Ja, prenumerationen har sin egen livslängd, som ställs in av operatören eller överenskommits med AS. När prenumerationen löper ut kommer PDN att inaktiveras på MME, och enheten kommer att bli otillgänglig för AS. I detta fall kommer funktionen "Enhetsutlösning" också att hjälpa. När SCEF tar emot ny data från AS kommer den att ta reda på enhetens anslutningsstatus och leverera informationen via SMS-kanalen.

Slutsats

SCEF-funktionaliteten är naturligtvis inte begränsad till de ovan beskrivna tjänsterna och utvecklas och expanderas ständigt. För närvarande har mer än ett dussin tjänster redan standardiserats för SCEF. Nu har vi bara berört de viktigaste och mest populära funktionerna bland utvecklare, vi kommer att prata om resten i framtida artiklar.

Frågan uppstår omedelbart: hur får man teståtkomst till denna "mirakel"-nod för preliminär testning och felsökning av möjliga fall? Allt är väldigt enkelt. Alla utvecklare kan skicka en förfrågan till iot.info@mts.ru, där det räcker med att ange syftet med anslutningen, en beskrivning av det möjliga fallet och kontaktinformation för kommunikation.

Vi ses igen!

Författare:

• Senior expert på avdelningen för konvergenta lösningar och multimediatjänster, Sergey Novikov sanov,
• expert på avdelningen för konvergenta lösningar och multimediatjänster Alexey Lapshin aslapsh

Källa: will.com