NB-IoT: hur fungerar det? Del 3: SCEF – ett 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 utseendet på en ny SCEF-nod. Vi förklarar i den tredje delen vad det är och varför det behövs?

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

• hur man identifierar enheter;
• vilken verifierings- och autentiseringsalgoritm som ska användas;
• vilket transportprotokoll att välja för att interagera med enheter;
• hur man på ett tillförlitligt sätt levererar data till enheter;
• hur man organiserar och upprättar regler för utbyte av data med dem;
• hur man övervakar och får information om sitt tillstånd online;
• hur du samtidigt levererar data till en grupp av dina enheter;
• hur man samtidigt skickar data från en enhet till flera klienter;
• hur du får enhetlig åtkomst till ytterligare operatörstjänster för att hantera din enhet.

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

Enligt definitionen av 3GPP är SCEF (service capability exponeringsfunktion) en helt ny komponent i 3GPP-arkitekturen vars funktion är att på ett säkert sätt exponera de tjänster och möjligheter som tillhandahålls av 3GPP-nätverksgränssnitt via API:er.

Med enkla ord är SCEF en mellanhand mellan nätverket och applikationsservern (AS), ett enda fönster för åtkomst till operatörstjänster för att hantera din M2M-enhet i NB-IoT-nätverket genom ett intuitivt, standardiserat API-gränssnitt.

SCEF döljer komplexiteten i en operatörs nätverk, vilket gör att applikationsutvecklare kan abstrahera bort komplexa, enhetsspecifika mekanismer för att interagera med enheter.

Genom att omvandla nätverksprotokoll till ett välbekant API för applikationsutvecklare, underlättar SCEF API skapandet av nya tjänster och minskar tiden till marknaden. Den nya noden innehåller också funktioner för att identifiera/autenticera mobila enheter, definiera reglerna för datautbyte mellan enheten och AS, ta bort behovet för applikationsutvecklare att implementera dessa funktioner på sin sida, flytta dessa funktioner till operatörens axlar.

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 enhetstriggning, tillgång till ytterligare tjänster och operatörsnätverksmöjligheter.

Mot AS finns ett enda T8-gränssnitt, ett API (HTTP/JSON) standardiserat av 3GPP. Alla gränssnitt, med undantag för T8, fungerar baserat på DIAMETER-protokollet (fig. 1).

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

S6t – gränssnitt mellan SCEF och HSS. Krävs för autentisering av abonnenter, auktorisering av applikationsservrar, erhållande av en kombination av externt ID och IMSI/MSISDN, provisionering av övervakningshändelser och mottagning 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 enhetstriggning och SMS-överföring i NB-IoT-nätverk. Men i alla implementeringar är funktionaliteten hos denna nod integrerad i SCEF, så för att förenkla kretsen kommer vi inte att överväga det separat). Används för att få ruttinformation för att skicka SMS och interagera med SMS-centralen.

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

*i verkligheten finns det fler gränssnitt, bara de mest grundläggande listas här. En fullständig lista finns i 3GPP 23.682 (4.3.2 Lista över referenspunkter).

Nedan är SCEFs nyckelfunktioner och tjänster:

• länka SIM-kortidentifieraren (IMSI) till externt ID;
• ö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 ASer;
• stöd för speciella UE-statusövervakningsfunktioner (MONTE – Monitoring Events);
• anordningsutlösning;
• tillhandahålla icke-IP-dataroaming.

Den grundläggande principen för interaktion mellan AS och SCEF bygger på det så kallade schemat. prenumerationer. Om det är nödvändigt att få åtkomst till någon SCEF-tjänst för en specifik UE, måste applikationsservern skapa ett abonnemang genom att skicka ett kommando till det specifika API:et för den begärda tjänsten och få en unik identifierare som svar. Efter vilket alla ytterligare åtgärder och kommunikationer med UE inom ramen för denna tjänst kommer att ske med hjälp av denna identifierare.

Externt ID: Universell enhetsidentifierare

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

Utvecklare behöver inte längre implementera enhetsautentiseringsalgoritmer, nätverket tar helt över denna funktion. Externt ID är knutet till IMSI, och utvecklaren kan vara säker på att när den kommer åt ett specifikt externt ID interagerar det med ett specifikt SIM-kort. När du använder ett SIM-chip får du en helt 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 det externa ID:n unikt identifierar en specifik applikation som ansvarar för en specifik tjänst på en specifik enhet.

En gruppidentifierare visas också - 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 förenade i en enda logisk grupp.

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

Överföring av icke-IP-trafik (Non-IP Data Delivery, NIDD)

I NB-IoT, som en del av optimeringen av mekanismer för att överföra små mängder data, utöver de redan befintliga PDN-typerna, som IPv4, IPv6 och IPv4v6, har en annan typ dykt upp - icke-IP. I detta fall 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: klassisk - MME -> SGW -> PGW och sedan genom PtP-tunneln till AS (Fig. 2) eller med hjälp av SCEF (Fig. 3).

Den klassiska metoden erbjuder inga speciella fördelar jämfört med IP-trafik, förutom att minska storleken på överförda paket på grund av frånvaron av IP-huvuden. Användningen av SCEF öppnar upp för ett antal nya möjligheter och förenklar avsevärt procedurerna för att interagera med enheter.

När du överför 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 sin 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, genom en NAT-nod, där den grå adressen översätts till vit. Kombinationen 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 sker något datautbyte med den här enheten inom 5 minuter kommer anslutningen att sönderfalla och enheten kommer inte längre att vara tillgänglig på den vita adress som sessionen med AS initierades med. Det finns flera lösningar:

1. Använd hjärtslag. När en anslutning väl har upprättats måste enheten byta paket med AS med några minuters mellanrum, vilket förhindrar att NAT-översättningar stängs. Men någon energieffektivisering kan det inte vara tal om här.

2. Varje gång, om nödvändigt, kontrollera tillgängligheten av paket för enheten på AS - skicka ett meddelande till upplänken.

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

4. Slutligen, det mest lämpliga 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 enheten omregistreras, kommer den att få en ny IPv6-adress och kommer inte längre att vara tillgänglig med den tidigare.

Följaktligen är det nödvändigt att skicka något initialiseringspaket med en enhetsidentifierare 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 några strikta krav på autonomi och som ett resultat av det finns inga begränsningar för sändningstid 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 enhetsidentifieraren för ett AS är ett externt ID 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 energisparläge, kommer data att buffras och levereras när enheten blir tillgänglig. Om enheten är tillgänglig för trafik kommer data att levereras omedelbart. Detsamma gäller för ledningsgrupper.

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

Buffertmekanismen kan också användas vid sändning av MO-data från UE till AS. Om SCEF inte kunde leverera data till AS omedelbart, till exempel om underhållsarbete pågår på AS-servrarna, kommer dessa paket att buffras och garanteras att levereras så snart AS blir tillgängligt.

Som noterats ovan regleras åtkomst 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 den unika möjligheten att samtidigt använda data från en UE av flera ASer. De där. om flera AS har abonnerat på en UE, kommer SCEF efter att ha mottagit data från UE att skicka det till alla abonnerade AS. Detta är väl lämpat för 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 körs på NB-IoT kan du sälja data från dem till många tjänster samtidigt.

Garanterad meddelandeleveransmekanism

Reliable Data Service är en mekanism för garanterad leverans av MO- och MT-meddelanden utan användning av specialiserade algoritmer på protokollnivå, som till exempel handskakning i TCP. Det fungerar genom att inkludera en speciell flagga i servicedelen av meddelandet när det utbyts mellan UE och SCEF. Huruvida denna mekanism ska aktiveras eller inte vid sändning av trafik bestäms av AS.

Om mekanismen är aktiverad inkluderar UE:n en speciell flagga i overheaddelen av paketet när den kräver garanterad leverans av MO-trafik. Vid mottagande av ett sådant paket svarar SCEF:n UE:n med en bekräftelse. Om UE:n inte tar emot bekräftelsepaketet kommer paketet mot SCEF att återsändas. Samma sak händer för MT-trafiken.

Enhetsövervakning (övervakning av händelser - MONTE)

Som nämnts ovan inkluderar SCEF-funktionaliteten bland annat funktioner för att övervaka tillståndet hos UE, den sk. enhetsövervakning. Och om nya identifierare och dataöverföringsmekanismer ä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 tillåter AS att övervaka enhetsparametrar såsom anslutningsstatus, kommunikationstillgänglighet, plats, roamingstatus, etc. Vi kommer att prata om var och en mer i detalj lite senare.

Om det är nödvändigt att aktivera någon övervakningshändelse för en enhet eller grupp av enheter, prenumererar AS på motsvarande tjänst genom att skicka motsvarande API MONTE-kommando till SCEF, vilket inkluderar parametrar som externt ID eller externt grupp-ID, AS-identifierare, övervakning typ, antal rapporter, som AS vill ta emot. Om AS är auktoriserat att utföra begäran kommer SCEF, beroende på typen, att tillhandahålla 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.

Tillhandahållande av alla händelser, med undantag för "Antal UE som finns i ett geografiskt område", sker via HSS. Två händelser "Change of IMSI-IMEI Association" och "Roaming Status" spåras direkt på HSS, resten kommer att tillhandahållas av HSS på MME.
Händelser kan vara antingen engångs- eller periodiska och bestäms av deras typ.

Att skicka en rapport om en händelse (rapportering) utförs av noden som spårar händelsen direkt till SCEF (fig. 5).

Viktig punkt: Övervakningshändelser kan appliceras 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 ta en närmare titt på var och en av övervakningshändelserna:

Förlust av anslutning — informerar AS om att UE inte längre är tillgänglig för vare sig datatrafik eller signalering. Händelsen inträffar när "mobil nåbarhetstimern" för UE löper ut på MME. I en begäran om denna typ av övervakning kan AS:t ange dess "Maximum Detection Time"-värde - om UE:n inte visar någon aktivitet under denna tid kommer AS:n att informeras om att UE:n är otillgänglig, med angivande av orsaken. Händelsen inträffar också om UE med tvång togs bort av nätverket av någon anledning.

* För att låta nätverket veta att enheten fortfarande är tillgänglig initierar den med jämna mellanrum en uppdateringsprocedur - Tracking Area Update (TAU). Frekvensen för denna procedur ställs in av nätverket med timer T3412 eller (T3412_extended i fallet med PSM), vars värde överförs till enheten under Attach-proceduren eller nästa TAU. Mobil nåbarhetstimer är vanligtvis flera minuter längre än T3412. Om UE inte har gjort en TAU före utgången av "Mobil nåbarhetstimern", anser nätverket att den inte längre är nåbar.

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

Platsrapportering – Den här typen av övervakningshändelser tillåter AS att fråga efter UE:s plats. Antingen den aktuella platsen (nuvarande plats) eller den senast kända platsen (bestäms av det cell-ID från vilket enheten gjorde TAU eller överförde trafik senast) kan begäras, vilket är relevant för enheter i PSM- eller eDRX-energisparlägen. För "nuvarande plats" kan AS begära upprepade svar, där MME informerar AS varje gång enhetens plats ändras.

Byte av IMSI-IMEI Association – När denna händelse är aktiverad börjar SCEF övervaka ändringar i kombinationen av IMSI (SIM-kortidentifierare) och IMEI (enhetsidentifierare). När en händelse inträffar, informerar AS. Kan användas för att automatiskt binda om ett externt ID till en enhet under schemalagt utbytesarbete eller fungera som en identifierare för stöld av en enhet.

Roamingstatus – denna typ av övervakning används av AS för att avgöra om UE finns i hemnätverket eller i nätverket hos en roamingpartner. Alternativt kan PLMN (Public Land Mobile Network) för operatören där enheten är registrerad överföras.

Kommunikationsfel — Denna typ av övervakning informerar AS om fel i kommunikationen med enheten, baserat på orsakerna till anslutningsbortfallet (frigöringsorsakskod) som tagits emot från radioaccessnätverket (S1-AP-protokoll). Denna händelse kan hjälpa till att avgöra varför kommunikationen misslyckades - på grund av problem i nätverket, till exempel när eNodeb är överbelastad (radioresurser inte tillgängliga) eller på grund av ett fel på själva enheten (Radio Connection With UE Lost).

Tillgänglighet efter DDN-fel – denna händelse informerar AS om att enheten har blivit tillgänglig efter ett kommunikationsfel. Kan användas när det finns ett behov av att överföra data till en enhet, men det tidigare försöket misslyckades eftersom UE inte svarade på ett meddelande från nätverket (personsökning) och data inte levererades. Om denna typ av övervakning har begärts för UE:n, så snart enheten gör en inkommande kommunikation, gör en TAU eller skickar data till upplänken, kommer AS att informeras om att enheten har blivit tillgänglig. 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 ändras (PDN-anslutningsstatus) - anslutning (PDN-aktivering) eller frånkoppling (PDN-radering). Detta kan användas av AS för att initiera kommunikation med UE, 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 som finns i ett geografiskt område – Denna typ av övervakning används av AS för att bestämma antalet UE i ett visst geografiskt område.

Enheten utlöses)

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

NB-IoT definierar en anslutningsmetod som "anslut utan PDN", det vill säga UE ansluter utan att upprätta en PDN-anslutning. I det här fallet är den inte tillgänglig för att överföra trafik och kan bara ta emot eller skicka SMS. För att skicka ett kommando till en sådan enhet för att aktivera PDN och ansluta till AS, utvecklades funktionen "Device triggering".

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

Det kan finnas tillfällen när ditt enhetsabonnemang löper ut på SCEF. Ja, prenumerationen har sin egen livslängd, fastställd av operatören eller överenskommen med AS. Vid utgången kommer PDN att avaktiveras på MME och enheten blir otillgänglig för AS. I det här fallet kommer funktionen "Device triggering" också att hjälpa. När ny data tas emot från AS kommer SCEF att ta reda på enhetens anslutningsstatus och leverera data via SMS-kanal.

Slutsats

Funktionaliteten hos SCEF är naturligtvis inte begränsad till tjänsterna som beskrivs ovan utan utvecklas och expanderar ständigt. För närvarande har mer än ett dussin tjänster redan standardiserats för SCEF. Nu har vi bara berört huvudfunktionerna som efterfrågas av 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 in en begäran till [e-postskyddad], där det räcker att ange syftet med anslutningen, en beskrivning av ett eventuellt ärende och kontaktuppgifter 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