NB-IoT: Hur fungerar det? Del 3: SCEF – ett enhetligt tillgångsfönster till operatörens tjänster

I artikeln "NB-IoT: hur fungerar det? Del 2", när vi talade om arkitekturen för nätets NB-IoT-paketkärna, nämnde vi införandet av den nya SCEF-noden. I tredje delen förklarar vi vad detta är och varför det behövs?

Vid skapandet av M2M-tjänster ställs applikationsutvecklare inför följande frågor:

• hur man identifierar enheter;
• vilken algoritm som ska användas för verifiering och autentisering;
• vilken transportprotokoll som ska väljas för interaktion med enheter;
• hur man garanterat levererar data till enheterna;
• hur man organiserar och etablerar regler för datautbyte med dem;
• hur man övervakar och får information om deras status i realtid;
• hur man samtidigt levererar data till en grupp av sina enheter;
• hur man samtidigt skickar data från en enhet till flera kunder;
• hur man får en enhetlig åtkomst till ytterligare operatörtjänster för att hantera sin enhet.

För att lösa dessa problem måste man skapa proprietära, tekniskt "tunga" lösningar, vilket leder till ökad arbetsinsats och längre time-to-market för tjänster. Här kommer den nya SCEF-noden till hjälp.

Enligt 3GPP:s definition ä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.

Enkelt uttryckt är SCEF en mellanhand mellan nätverket och applikationsservern (application server — AS), en enhetlig åtkomstpunkt för operatörens tjänster för att hantera sin M2M-enhet i NB-IoT-nätverket via ett intuitivt och standardiserat API-gränssnitt.

SCEF döljer nätverksoperatörens komplexitet, vilket gör att applikationsutvecklare kan abstrahera sig från de komplicerade, specifika interaktionsmekanismerna med enheter.

Genom att omvandla nätverksprotokoll till ett välbekant API-gränssnitt för applikationsutvecklare underlättar SCEF skapandet av nya tjänster och minskar time-to-market. Den nya noden inkluderar också funktioner för identifiering/autentisering av mobila enheter, fastställande av regler för datakommunikation mellan enheten och AS, vilket befriar applikationsutvecklarna från att behöva implementera dessa funktioner på sin sida och lägger ansvaret för dessa funktioner på operatören.

SCEF hanterar de gränssnitt som krävs för autentisering och auktorisering av applikationsservrar, upprätthållande av UE-mobilitet, datatransmission och enhetsutlösning, tillgång till extra tjänster och operatörens nätverksfunktioner.

Det finns ett enda gränssnitt T8 riktat mot AS, API-gränssnittet (HTTP/JSON), som är standardiserat av 3GPP. Alla gränssnitt, med undantag av T8, fungerar på DIAMETER-protokollet (se bild 1).

T6a – gränssnittet mellan SCEF och MME. Används för procedurer för mobilitet/sessionhantering, överföring av non-IP-data, provisionering av övervakningsevent och mottagning av rapporter om dessa.

S6t – gränssnittet mellan SCEF och HSS. Nödvändig för autentisering av abonnenter, auktorisering av applikationsservrar, mottagning av kopplingar av external ID och IMSI/MSISDN, provisionering av övervakningsevent och mottagning av rapporter om dessa.

S6m/T4 – gränssnitt från SCEF till HSS och SMS-C (i 3GPP definieras noden MTC-IWF, som används för enhetsutlösning och SMS-överföring i NB-IoT-nät. Emellertid har alla implementeringar denna nods funktionalitet integrerad i SCEF, så vi kommer att förenkla schemat genom att inte betrakta den separat). Används för att få ruttinformation för att skicka SMS och interagera med SMS-centralen.

T8 – API-gränssnitt för interaktion mellan SCEF och applikationsservrar. Genom detta gränssnitt sänds både styrkommandon och trafik.

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

Nedan anges nyckelfunktioner och tjänster från SCEF:

• bindning av SIM-kortsidentifikator (IMSI) till external ID;
• överföring av non-IP-trafik (Non-IP Data Delivery, NIDD);
• gruppoperationer med användning av external group ID;
• stöd för datatransmission 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 speciella funktioner för övervakning av UE-status (MONTE – Monitoring Events);
• utlösning av enheter;
• säkerställande av roaming av non-IP-data.

Den grundläggande principen för interaktionen mellan AS och SCEF baseras på så kallade prenumerationer. Vid behov av åtkomst till en viss tjänst SCEF för en specifik UE, måste applikationsservern skapa en prenumeration genom att skicka en kommando till den specifika API för den begärda tjänsten och i svar få ett unikt identifieringsnummer. Därefter kommer alla framtida åtgärder och kommunikationer med UE inom ramen för denna tjänst att ske med hjälp av detta identifieringsnummer.

Extern ID: universell identifierare för enheten

En av de viktigaste förändringarna i interaktionsschemat mellan AS och enheter vid arbete genom SCEF är införandet av en universell identifierare. Nu, istället för telefonnumret (MSISDN) eller IP-adressen, som i det klassiska 2G/3G/LTE-nätverket, blir "external ID" identifieraren för enheten för applikationsservern. Den definieras av standarden i det format som är bekant för applikationsutvecklare: "@".

Utvecklare behöver inte längre implementera autentiseringsalgoritmer för enheter, nätverket tar fullt ansvar för denna funktion. External ID kopplas till IMSI, och utvecklaren kan vara säker på att när de adresserar ett specifikt external ID, interagerar de med ett specifikt SIM-kort. Vid användning av ett SIM-kort uppstår en helt unik situation där external ID entydigt identifierar den specifika enheten!

Dessutom kan flera external ID kopplas till ett enda IMSI, vilket skapar en ännu mer intressant situation där external ID entydigt identifierar en specifik applikation som ansvarar för en viss tjänst på en specifik enhet.

Det introduceras också en gruppidentifierare – external group ID, som inkluderar en uppsättning av individuella external ID. Nu kan AS med ett enda anrop till SCEF initiera gruppoperationer – skicka data eller kommandon till flera enheter som är sammanbundna i en enda logisk grupp.

På grund av att övergången till den nya enhetsidentifieraren för AS inte kan ske omedelbart, har SCEF lämnat möjligheten för kommunikation mellan AS och UE genom standardnumret – MSISDN.

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

I NB-IoT, i samband med optimering av mekanismer för överföring av små datamängder, tillkom ett nytt typ av PDN utöver de redan existerande typerna som IPv4, IPv6 och IPv4v6 — non-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 routas på två sätt: det klassiska sättet — MME -> SGW -> PGW och vidare genom PtP-tunnel till AS (figur 2) eller med användning av SCEF (figur 3).

Det klassiska sättet erbjuder inga särskilda fördelar jämfört med IP-trafik, förutom en minskning av storleken på de överförda paketen tack vare avsaknaden av IP-headers. Användning av SCEF öppnar dock en hel rad nya möjligheter och förenklar i hög grad interaktionsprocedurer 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 extern ID

För att skicka ett meddelande till en klassisk IP-enhet måste AS veta dess IP-adress. Här uppstår ett problem: eftersom enheten vid registreringen normalt får en "grå" IP-adress, kommunicerar den med applikationsservern som är belägen på internet genom en NAT-nod, där den grå adressen översätts till en offentlig. Kopplingen mellan den grå och den offentliga IP-adressen hålls under en begränsad tid, beroende på NAT-inställningarna. I genomsnitt för TCP eller UDP — högst fem minuter. Det vill säga om det inte har skett någon datakommunikation med denna enhet under 5 minuter, så spricker kopplingen, och enheten blir otillgänglig via den offentliga adressen som sessionen med AS initierades. Det finns flera lösningar:

1. Använda heartbeat. Genom att en gång etablera en anslutning bör enheten utbyta paket med AS var några minuter och därmed förhindra att NAT-översättningarna stängs av. Men här kan det inte talas om någon energieffektivitet.

2. Varje gång, vid behov, kontrollera om det finns paket för enheten på AS — skicka ett meddelande i uplink.

3. Skapa en privat APN (VRF), där applikationsservern och enheterna finns i samma subnet, och tilldela statiska IP-adresser till enheterna. Det kommer att fungera, men det är nästan omöjligt att genomföra när det handlar om en park med tusentals, tiotusentals enheter.

4. Slutligen, det mest lämpliga alternativet: att använda IPv6, eftersom det inte kräver NAT, då IPv6-adresser är direkt tillgängliga från internet. Men även i detta fall, vid omregistrering av en enhet, kommer den att få en ny IPv6-adress och blir inte längre tillgänglig via den tidigare.

Därför måste man skicka ett initierande paket med enhetens identifierare till servern för att meddela den nya IP-adressen för enheten. Sedan väntar man på bekräftelsepaketet från AS, vilket också påverkar energieffektiviteten.

Dessa metoder fungerar bra för 2G/3G/LTE-enheter, där det inte ställs strikta krav på enhetens autonomi, och därmed finns det inga begränsningar avseende tid i luften eller trafik. För NB-IoT fungerar dessa metoder inte på grund av deras hög energiförbrukning.

SCEF löser detta problem: eftersom den enda identifieraren för enheten för AS är external ID, räcker det för AS att skicka ett datapaket till SCEF för det specifika external ID:t, medan SCEF tar hand om resten. Om enheten är i energisparläge PSM eller eDRX 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. Detta gäller även för styrkommandon.

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

Buffringsmekanismen kan också tillämpas vid överföring av MO-data från UE till AS. Om SCEF inte kunde leverera data till AS omedelbart, till exempel om servicearbete pågår på AS-servrarna, kommer dessa paket att buffras och garanterat levereras så snart AS blir tillgänglig.

Som nämnts ovan regleras åtkomsten till en viss tjänst och UE för AS (och NIDD är en tjänst) av regler och politik på SCEF-sidan, vilket möjliggör 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 anmält sig till en UE, kommer SCEF att distribuera data till alla registrerade AS efter att ha mottagit information från UE. Detta passar bra för fall där skaparen av en park med specialiserade enheter delar data mellan flera kunder. Till exempel, genom att skapa ett nätverk av väderstationer som arbetar på NB-IoT kan man sälja data från dem till många tjänster samtidigt.

Mekanism för garanterad meddelandeleverans

Reliable Data Service — 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 särskild flagga i meddelandets tjänstedel under utbytet mellan UE och SCEF. Att aktivera eller inte aktivera denna mekanism vid överföring av trafik bestäms av AS.

Om mekanismen är aktiverad inkluderar UE, vid behov av garanterad leverans av MO-trafik, en särskild flagga i paketets tjänstedel. Vid mottagande av ett sådant paket svarar SCEF UE med en bekräftelse. Om UE inte mottar paketet med bekräftelsen kommer paketet mot SCEF att skickas om. Detsamma gäller för MT-trafik.

Övervakning av enheter (monitoring events- MONTE)

Som nämnts ovan inkluderar SCEF:s funktionalitet förutom andra saker funktioner för övervakning av UE:s tillstånd, så kallad övervakning av enheter. Och medan nya identifierare och mekanismer för dataöverföring är optimeringar (även om de är mycket allvarliga) av redan befintliga procedurer, är MONTE en helt ny funktionalitet som inte är tillgänglig i 2G/3G/LTE-nät. MONTE gör det möjligt för AS att övervaka parametrar som enhetens anslutningsstatus, kommunikationsbarhet, plats, roamingstatus etc. Mer om varje ämne kommer vi att berätta senare.

Om det är nödvändigt att aktivera någon övervakning för en enhet eller en grupp enheter anmäler sig AS till den aktuella tjänsten genom att skicka ett kommando till SCEF via motsvarande MONTE API, vilket inkluderar parametrar som external Id eller external group ID, identifierare för AS, typ av övervakning, antal rapporter som AS vill ta emot. Om AS är auktoriserad för att genomföra förfrågan provisionerar SCEF händelsen beroende på typ på HSS eller MME (se bild 4). Vid händelsens inträffande genererar MME eller HSS en rapport till SCEF, som skickar den vidare till AS.

Provisionering av alla händelser, med undantag för "Antal UE:er närvarande i ett geografiskt område", sker via HSS. De två händelserna "Ändring av IMSI-IMEI-förening" och "Roamingstatus" övervakas direkt på HSS, övriga provisionerar HSS till MME.
Händelser kan vara både engångs- och periodiska och bestäms av deras typ.

Rapportering av händelser sker genom en nod som spårar händelsen direkt till SCEF (fig. 5).

Viktigt att notera: övervakningshändelser kan tillämpas både på non-IP-enheter som är anslutna via SCEF och på IP-enheter som överför data på traditionellt sätt via MME-SGW-PGW.

Låt oss titta närmare på varje övervakningshändelse:

Förlust av anslutning – informerar AS om att UE inte längre är tillgänglig för varken datatrafik eller signalutbyte. Händelsen inträffar när "mobile reachability timer" för UE löper ut på MME. I förfrågan om denna typ av övervakning kan AS ange sitt värde för "Maximum Detection Time" – om UE inte visar någon aktivitet under denna tid kommer AS att informeras om att UE är otillgänglig med angiven orsak. Händelsen inträffar också om UE av någon anledning har tvingats bort av nätverket.

* För att nätverket ska veta att enheten fortfarande är tillgänglig initierar den periodiskt en uppdateringsprocedur – Tracking Area Update (TAU). Frekvensen för denna procedur ställs in av nätverket genom en timer T3412 eller (T3412_extended i fallet med PSM), vars värde överförs till enheten under Attach-proceduren eller nästa TAU. Mobile reachability timer är vanligtvis några minuter längre än T3412. Om UE inte gör TAU innan "Mobile reachability timer" löper ut anser nätverket att den inte längre är tillgänglig.

UE tillgänglighet – Visar när UE blir tillgänglig för DL-trafik eller SMS. Detta inträffar när UE blir tillgänglig för paging (för UE i läge eDRX) eller när UE går in i läge ECM-CONNECTED (för UE i läge PSM eller eDRX), d.v.s. gör TAU eller skickar en uplink-paket.

Platsrapportering – Denna typ av övervakningshändelser gör det möjligt för AS att begära data om UE:s plats. Antingen kan den aktuella platsen (Current Location) begäras, eller den senaste kända platsen (Last Known Location, som bestäms av cell-ID från vilket enheten gjorde TAU eller överförde trafik senast), vilket är relevant för enheter som befinner sig i energisparlägen PSM eller eDRX. För "Current Location" kan AS begära repetitiva rapporter, där MME informerar AS varje gång enheten ändrar plats.

Ändring av IMSI-IMEI-association – När detta händelse aktiveras börjar SCEF att övervaka förändringar i kopplingen mellan IMSI (SIM-kortsidentifierare) och IMEI (enhetsidentifierare). Vid händelsens inträffande informeras AS. Kan användas för automatisk återkoppling av extern ID till enheten under planerade byten eller fungera som identifierare för stöld av en enhet.

Roaming-status – denna typ av övervakning används av AS för att avgöra om UE befinner sig i sitt hemmannät eller i en roamingpartners nät. Optionellt kan PLMN (Public Land Mobile Network) från operatören där enheten är registrerad sändas.

Kommunikationsfel — Denna typ av övervakning informerar AS om fel i kommunikationen med enheten, baserat på orsakerna till anslutningsbrott (release cause code) mottagna från radiotillgångsnätverket (S1-AP-protokollet). Denna händelse kan hjälpa att avgöra varför kommunikationsfelet inträffade — på grund av problem i nätverket, exempelvis vid överbelastning av eNodeb (Radio resources not available) eller på grund av ett fel i själva enheten (Radio Connection With UE Lost).

Tillgänglighet efter DDN-fel – denna händelse informerar AS att enheten har blivit tillgänglig efter ett kommunikationsfel. Kan användas när det är nödvändigt att skicka data till enheten, men tidigare försök misslyckades eftersom UE inte svarade på nätverksnotifikationen (paging), och data inte levererades. Om denna typ av övervakning begärdes för UE, så snart enheten initierar en inkommande kommunikation, gör TAU eller skickar data i uplink, kommer AS att informeras om att enheten blivit tillgänglig. Eftersom DDN (downlink data notification) processen fungerar mellan MME och S/P-GW, är denna typ av övervakning endast tillgänglig för IP-enheter.

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

Antal UEs närvarande i ett geografiskt område – denna typ av övervakning används av AS för att avgöra antalet UE i ett specifikt geografiskt område.

Utmaning av enheter (Device triggering)

I 2G/3G-nätverk var processen för nätregistrering tvåstegslös: först registrerades enheten i SGSN (attach-procedur), sedan aktiverade den PDP-kontakt – anslutningen till paketgatewayen (GGSN) när det behövdes för att överföra data. I 3G-nätverk gick dessa två procedurer efter varandra, dvs. enheten väntade inte på att behöva överföra data utan aktiverade PDP direkt efter att attach-proceduren slutförts. I LTE har dessa två procedurer kombinerats till en, vilket innebär att enheten begärde aktivering av PDN-anslutning (motsvarigheten till PDP i 2G/3G) direkt vid attach genom eNodeB till MME-SGW-PGW.

I NB-IoT definieras en anslutningsmetod som "attach without PDN", vilket innebär att UE gör en attach utan att upprätta PDN-anslutning. I detta fall är den inte tillgänglig för trafiköverföring och kan endast ta emot eller skicka SMS. För att överföra en aktiveringskommandon för PDN och anslutning till AS till en sådan enhet har "Device triggering"-funktionen utvecklats.

Vid mottagandet av en anslutning från AS, initierar SCEF genom SMS-centret att skicka en styrande SMS till enheten. Vid mottagandet av SMS aktiverar enheten PDN och ansluter till AS för att ta emot kommande instruktioner eller överföra data.

Det kan hända att prenumerationen på enheten hos SCEF löper ut. Ja, prenumerationen har en livslängd som fastställs av operatören eller överenskommelser med AS. Vid utgången av denna på MME kommer PDN att avaktiveras och enheten blir otillgänglig för AS. Här kan också "Device triggering"-funktionen vara till hjälp. När nya data tas emot från AS kommer SCEF att kontrollera statusen för enhetens anslutning och leverera data via SMS-kanalen.

Slutsats

SCEF-funktionen begränsas givetvis inte till de ovan nämnda tjänsterna utan utvecklas och expanderar ständigt. För tillfället har mer än ett dussin tjänster standardiserats för SCEF. Nu har vi bara berört de grundläggande och efterfrågade funktionerna från utvecklare, medan vi kommer att prata om de andra i framtida artiklar.

Frågan uppstår genast, hur kan man få teståtkomst till denna "mirakulösa" nod för förhandsgranskning och avstämning av möjliga fall? Allt är mycket enkelt. Varje utvecklare kan skicka en begäran till iot.info@mts.ru, där det är tillräckligt att ange syftet med anslutningen, en beskrivning av det möjliga fallet och kontaktinformation för kommunikation.

Vi ses snart igen!

Författare:

• senior expert inom konvergerande lösningar och multimedietjänster Sergey Novikov sanov,
• expert inom konvergerande lösningar och multimedietjänster Aleksey Lapshin aslapsh

Källa: habr.com