NB-IoT: hvordan virker det? Del 3: SCEF – enkelt vindue for adgang til operatørtjenester

I artiklen "NB-IoT: hvordan virker det? Del 2", når vi taler om arkitekturen af ​​pakkekernen i NB-IoT-netværket, nævnte vi udseendet af en ny SCEF-knude. Vi forklarer i tredje del, hvad det er, og hvorfor det er nødvendigt?

Når du opretter en M2M-tjeneste, står applikationsudviklere over for følgende spørgsmål:

• hvordan man identificerer enheder;
• hvilken verifikations- og autentificeringsalgoritme der skal bruges;
• hvilken transportprotokol der skal vælges til interaktion med enheder;
• hvordan man pålideligt leverer data til enheder;
• hvordan man organiserer og etablerer regler for udveksling af data med dem;
• hvordan man overvåger og får information om deres tilstand online;
• hvordan du samtidig leverer data til en gruppe af dine enheder;
• hvordan man samtidig sender data fra én enhed til flere klienter;
• hvordan du får samlet adgang til yderligere operatørtjenester til at administrere din enhed.

For at løse dem er det nødvendigt at skabe proprietære teknisk "tunge" løsninger, hvilket fører til øgede lønomkostninger og time-to-market services. Det er her den nye SCEF-node kommer til undsætning.

Som defineret af 3GPP er SCEF (service capability exposure function) en helt ny komponent i 3GPP-arkitekturen, hvis funktion er at afsløre de tjenester og muligheder, som 3GPP-netværksgrænseflader leverer sikkert gennem API'er.

Med enkle ord er SCEF et mellemled mellem netværket og applikationsserveren (AS), et enkelt vindue med adgang til operatørtjenester til styring af din M2M-enhed i NB-IoT-netværket gennem en intuitiv, standardiseret API-grænseflade.

SCEF skjuler kompleksiteten af ​​en operatørs netværk, hvilket giver applikationsudviklere mulighed for at abstrahere komplekse, enhedsspecifikke mekanismer til interaktion med enheder.

Ved at transformere netværksprotokoller til en velkendt API for applikationsudviklere letter SCEF API oprettelsen af ​​nye tjenester og reducerer time-to-market. Den nye node indeholder også funktioner til at identificere/autentificere mobile enheder, definere reglerne for dataudveksling mellem enheden og AS, fjerne behovet for applikationsudviklere til at implementere disse funktioner på deres side, flytte disse funktioner til operatørens skuldre.

SCEF dækker de grænseflader, der er nødvendige for autentificering og godkendelse af applikationsservere, opretholdelse af UE-mobilitet, dataoverførsel og enhedsudløsning, adgang til yderligere tjenester og operatørnetværksmuligheder.

Mod AS'et er der en enkelt T8-grænseflade, en API (HTTP/JSON) standardiseret af 3GPP. Alle grænseflader, med undtagelse af T8, fungerer baseret på DIAMETER-protokollen (fig. 1).

T6a – grænseflade mellem SCEF og MME. Anvendes til mobilitets-/sessionsstyringsprocedurer, transmission af ikke-IP-data, levering af overvågningshændelser og modtagelse af rapporter om dem.

S6t – grænseflade mellem SCEF og HSS. Påkrævet til abonnentgodkendelse, autorisation af applikationsservere, opnåelse af en kombination af eksternt ID og IMSI/MSISDN, levering af overvågningshændelser og modtagelse af rapporter om dem.

S6m/T4 – grænseflader fra SCEF til HSS og SMS-C (3GPP definerer MTC-IWF noden, som bruges til enhedsudløsning og SMS transmission i NB-IoT netværk. Men i alle implementeringer er funktionaliteten af ​​denne node integreret i SCEF, så for at forenkle kredsløbet vil vi ikke overveje det separat). Bruges til at indhente ruteoplysninger til afsendelse af SMS og interaktion med SMS-centeret.

T8 – API-grænseflade til SCEF-interaktion med applikationsservere. Både kontrolkommandoer og trafik transmitteres gennem denne grænseflade.

*i virkeligheden er der flere grænseflader; kun de mest basale er angivet her. En komplet liste findes i 3GPP 23.682 (4.3.2 Liste over referencepunkter).

Nedenfor er de vigtigste funktioner og tjenester i SCEF:

• at forbinde SIM-kortidentifikationen (IMSI) til eksternt ID;
• transmission af ikke-IP-trafik (Non-IP Data Delivery, NIDD);
• gruppeoperationer ved hjælp af eksternt gruppe-id;
• understøttelse af datatransmissionstilstand med bekræftelse;
• buffering af MO (Mobile Originated) og MT (Mobile Terminated) data;
• autentificering og godkendelse af enheder og applikationsservere;
• samtidig brug af data fra en UE af flere AS'er;
• understøttelse af særlige UE-statusovervågningsfunktioner (MONTE – Monitoring Events);
• enhedsudløsning;
• leverer ikke-IP dataroaming.

Det grundlæggende princip for samspil mellem AS og SCEF er baseret på den såkaldte ordning. abonnementer. Hvis det er nødvendigt at få adgang til en hvilken som helst SCEF-tjeneste for en specifik UE, skal applikationsserveren oprette et abonnement ved at sende en kommando til den specifikke API for den anmodede tjeneste og modtage en unik identifikator som svar. Hvorefter alle yderligere handlinger og kommunikationer med UE inden for rammerne af denne tjeneste vil finde sted ved hjælp af denne identifikator.

Eksternt ID: Universal enheds-id

En af de vigtigste ændringer i interaktionsskemaet mellem AS og enheder, når du arbejder gennem SCEF, er udseendet af en universel identifikator. Nu, i stedet for et telefonnummer (MSISDN) eller IP-adresse, som det var tilfældet i det klassiske 2G/3G/LTE-netværk, bliver enhedsidentifikatoren for applikationsserveren "eksternt ID". Det er defineret af standarden i formatet "@", som applikationsudviklere kender.

Udviklere behøver ikke længere at implementere enhedsgodkendelsesalgoritmer; netværket overtager fuldstændig denne funktion. Eksternt ID er bundet til IMSI, og udvikleren kan være sikker på, at når den tilgår et bestemt eksternt ID, interagerer det med et specifikt SIM-kort. Når du bruger en SIM-chip, får du en helt unik situation, når det eksterne ID entydigt identificerer en bestemt enhed!

Desuden kan flere eksterne ID'er knyttes til én IMSI - en endnu mere interessant situation opstår, når det eksterne ID entydigt identificerer en specifik applikation, der er ansvarlig for en bestemt tjeneste på en bestemt enhed.

En gruppe-id vises også - eksternt gruppe-id, som inkluderer et sæt individuelle eksterne ID'er. Nu, med én anmodning til SCEF, kan AS starte gruppeoperationer - sende data eller styrekommandoer til flere enheder samlet i en enkelt logisk gruppe.

På grund af det faktum, at overgangen til en ny enhedsidentifikator for AS-udviklere ikke kan være øjeblikkelig, forlod SCEF muligheden for AS-kommunikation med UE gennem et standardnummer - MSISDN.

Transmission af ikke-IP-trafik (Non-IP Data Delivery, NIDD)

I NB-IoT er der som led i optimeringen af ​​mekanismer til transmission af små mængder data, udover de allerede eksisterende PDN-typer, såsom IPv4, IPv6 og IPv4v6, dukket en anden type op – ikke-IP. I dette tilfælde er enheden (UE) ikke tildelt en IP-adresse, og data overføres uden brug af IP-protokollen. Trafikken til sådanne forbindelser kan dirigeres på to måder: klassisk - MME -> SGW -> PGW og derefter gennem PtP-tunnelen til AS (fig. 2) eller ved hjælp af SCEF (fig. 3).

Den klassiske metode giver ingen særlige fordele i forhold til IP-trafik, bortset fra at reducere størrelsen af ​​transmitterede pakker på grund af fraværet af IP-headere. Brugen af ​​SCEF åbner op for en række nye muligheder og forenkler procedurerne for interaktion med enheder markant.

Når du overfører data via SCEF, fremstår to meget vigtige fordele i forhold til klassisk IP-trafik:


Levering af MT-trafik til enheden via eksternt ID

For at sende en besked til en klassisk IP-enhed skal AS'et kende sin IP-adresse. Her opstår et problem: Da enheden normalt modtager en "grå" IP-adresse ved registrering, kommunikerer den med applikationsserveren, som er placeret på internettet, gennem en NAT-node, hvor den grå adresse oversættes til hvid. Kombinationen af ​​grå og hvide IP-adresser varer i en begrænset periode, afhængigt af NAT-indstillingerne. I gennemsnit for TCP eller UDP - ikke mere end fem minutter. Det vil sige, at hvis der ikke er nogen dataudveksling med denne enhed inden for 5 minutter, vil forbindelsen gå i opløsning, og enheden vil ikke længere være tilgængelig på den hvide adresse, som sessionen med AS blev indledt med. Der er flere løsninger:

1. Brug hjerteslag. Når en forbindelse er etableret, skal enheden udveksle pakker med AS'en med få minutters mellemrum, og derved forhindre NAT-oversættelser i at lukke. Men der kan ikke være tale om nogen energieffektivitet her.

2. Hver gang, om nødvendigt, tjek tilgængeligheden af ​​pakker til enheden på AS'et - send en besked til uplinket.

3. Opret et privat APN (VRF), hvor applikationsserveren og enhederne vil være på det samme undernet, og tildel statiske IP-adresser til enhederne. Det vil virke, men det er næsten umuligt, når vi taler om en flåde på tusinder, titusinder af enheder.

4. Endelig den bedst egnede mulighed: brug IPv6, det kræver ikke NAT, da IPv6-adresser er direkte tilgængelige fra internettet. Men selv i dette tilfælde, når enheden genregistreres, vil den modtage en ny IPv6-adresse og vil ikke længere være tilgængelig med den forrige.

I overensstemmelse hermed er det nødvendigt at sende en initialiseringspakke med en enhedsidentifikator til serveren for at rapportere enhedens nye IP-adresse. Vent derefter på en bekræftelsespakke fra AS, som også påvirker energieffektiviteten.

Disse metoder fungerer godt for 2G/3G/LTE-enheder, hvor enheden ikke har strenge krav til autonomi, og som følge heraf er der ingen begrænsninger på sendetid og trafik. Disse metoder er ikke egnede til NB-IoT på grund af deres høje energiforbrug.

SCEF løser dette problem: da den eneste enhedsidentifikator for et AS er et eksternt ID, behøver AS kun at sende en datapakke til SCEF for et specifikt eksternt ID, og ​​SCEF tager sig af resten. Hvis enheden er i PSM- eller eDRX-strømsparetilstand, vil data blive bufferet og leveret, når enheden bliver tilgængelig. Hvis enheden er tilgængelig for trafik, vil dataene blive leveret med det samme. Det samme gælder for ledelsesteams.

AS'et kan til enhver tid genkalde den bufferlagrede meddelelse til UE'en eller erstatte den med en ny.

Buffermekanismen kan også bruges, når der transmitteres MO-data fra UE til AS. Hvis SCEF ikke var i stand til at levere data til AS'et med det samme, for eksempel hvis vedligeholdelsesarbejde er i gang på AS-serverne, vil disse pakker blive bufferet og garanteret at blive leveret, så snart AS'et bliver tilgængeligt.

Som nævnt ovenfor er adgang til en specifik service og UE for et AS (og NIDD er en service) reguleret af regler og politikker på SCEF-siden, hvilket giver mulighed for den unikke mulighed for samtidig brug af data fra en UE af flere AS'er. De der. hvis flere AS har abonneret på en UE, vil SCEF efter at have modtaget data fra UE'en sende dem til alle abonnerede AS. Dette er velegnet til tilfælde, hvor skaberen af ​​en flåde af specialiserede enheder deler data mellem flere klienter. For eksempel ved at oprette et netværk af vejrstationer, der kører på NB-IoT, kan du sælge data fra dem til mange tjenester samtidigt.

Garanteret beskedleveringsmekanisme

Reliable Data Service er en mekanisme til garanteret levering af MO- og MT-meddelelser uden brug af specialiserede algoritmer på protokolniveau, som for eksempel håndtryk i TCP. Det fungerer ved at inkludere et særligt flag i servicedelen af ​​beskeden, når den udveksles mellem UE og SCEF. Om denne mekanisme skal aktiveres eller ej, når der transmitteres trafik, bestemmes af AS.

Hvis mekanismen er aktiveret, inkluderer UE et særligt flag i overheaddelen af ​​pakken, når det kræver garanteret levering af MO-trafik. Efter modtagelse af en sådan pakke svarer SCEF'en til UE'en med en bekræftelse. Hvis UE ikke modtager bekræftelsespakken, vil pakken til SCEF blive sendt igen. Det samme sker for MT-trafikken.

Enhedsovervågning (overvågning af hændelser - MONTE)

Som nævnt ovenfor omfatter SCEF-funktionaliteten blandt andet funktioner til overvågning af UE'ens tilstand, den såkaldte. enhedsovervågning. Og hvis nye identifikatorer og dataoverførselsmekanismer er optimeringer (omend meget seriøse) af eksisterende procedurer, så er MONTE en helt ny funktionalitet, der ikke er tilgængelig i 2G/3G/LTE-netværk. MONTE giver AS mulighed for at overvåge enhedsparametre såsom forbindelsesstatus, kommunikationstilgængelighed, placering, roamingstatus osv. Vi vil tale om hver enkelt mere detaljeret lidt senere.

Hvis det er nødvendigt at aktivere en overvågningshændelse for en enhed eller gruppe af enheder, abonnerer AS på den tilsvarende tjeneste ved at sende den tilsvarende API MONTE-kommando til SCEF, som inkluderer parametre som eksternt Id eller eksternt gruppe-ID, AS-id, overvågning type, antal rapporter, som AS ønsker at modtage. Hvis AS er autoriseret til at udføre anmodningen, vil SCEF, afhængigt af typen, levere hændelsen til HSS eller MME (fig. 4). Når en hændelse opstår, genererer MME eller HSS en rapport til SCEF, som sender den til AS.

Tilvejebringelse af alle begivenheder, med undtagelse af "Antal UE'er til stede i et geografisk område", sker gennem HSS. To begivenheder "Change of IMSI-IMEI Association" og "Roaming Status" spores direkte på HSS, resten vil blive leveret af HSS på MME.
Begivenheder kan være enten engangs- eller periodiske og bestemmes af deres type.

Afsendelse af en rapport om en hændelse (rapportering) udføres af den node, der sporer hændelsen direkte til SCEF (fig. 5).

Vigtigt punkt: Overvågningshændelser kan anvendes på både ikke-IP-enheder forbundet via SCEF og IP-enheder, der transmitterer data på den klassiske måde via MME-SGW-PGW.

Lad os se nærmere på hver af overvågningsbegivenhederne:

Tab af forbindelse — informerer AS'et om, at UE ikke længere er tilgængelig for hverken datatrafik eller signalering. Hændelsen opstår, når "mobil nåbarhedstimeren" for UE'en udløber på MME'en. I en anmodning om denne type overvågning kan AS'et angive sin "maksimale detektionstid"-værdi - hvis UE i løbet af dette tidsrum ikke viser nogen aktivitet, vil AS'et blive informeret om, at UE'en er utilgængelig med angivelse af årsagen. Hændelsen opstår også, hvis UE blev tvangsfjernet af netværket af en eller anden grund.

* For at lade netværket vide, at enheden stadig er tilgængelig, starter den med jævne mellemrum en opdateringsprocedure - Tracking Area Update (TAU). Frekvensen af ​​denne procedure indstilles af netværket ved hjælp af timeren T3412 eller (T3412_extended i tilfælde af PSM), hvis værdi overføres til enheden under tilslutningsproceduren eller den næste TAU. Mobil tilgængelighedstimer er normalt flere minutter længere end T3412. Hvis UE ikke har lavet en TAU inden udløbet af "Mobile reachability timer", anser netværket det for ikke længere at være tilgængeligt.

UE tilgængelighed – Indikerer, hvornår UE bliver tilgængelig for DL-trafik eller SMS. Dette sker, når UE bliver tilgængelig for personsøgning (for en UE i eDRX-tilstand), eller når UE går ind i ECM-CONNECTED-tilstand (for en UE i PSM- eller eDRX-tilstand), dvs. laver en TAU eller sender en uplink-pakke.

Placeringsrapportering – Denne type overvågningshændelser giver AS'et mulighed for at forespørge efter UE'ens placering. Der kan anmodes om enten den aktuelle placering (Current Location) eller den sidst kendte placering (bestemt af det celle-id, som enheden lavede TAU fra eller sendte trafik fra sidste gang), hvilket er relevant for enheder i PSM- eller eDRX-strømsparetilstande. For "Nuværende placering" kan AS anmode om gentagne svar, hvor MME informerer AS, hver gang enhedens placering ændres.

Ændring af IMSI-IMEI Association – Når denne hændelse er aktiveret, begynder SCEF at overvåge ændringer i kombinationen af ​​IMSI (SIM-kortidentifikator) og IMEI (enhedsidentifikator). Når en hændelse opstår, informerer AS. Kan bruges til automatisk at genbinde et eksternt ID til en enhed under planlagt udskiftningsarbejde eller tjene som en identifikator for tyveri af en enhed.

Roamingstatus – denne type overvågning bruges af AS til at bestemme, om UE er i hjemmenetværket eller i en roamingpartners netværk. Eventuelt kan PLMN (Public Land Mobile Network) for den operatør, hvor enheden er registreret, sendes.

Kommunikationsfejl — Denne type overvågning informerer AS'et om fejl i kommunikationen med enheden baseret på årsagerne til forbindelsestabet (frigivelsesårsagskode) modtaget fra radioadgangsnetværket (S1-AP-protokol). Denne hændelse kan hjælpe med at afgøre, hvorfor kommunikationen mislykkedes - på grund af problemer på netværket, for eksempel når eNodeb'en er overbelastet (Radioressourcer ikke tilgængelige) eller på grund af en fejl på selve enheden (Radio Connection With UE Lost).

Tilgængelighed efter DDN-svigt – denne hændelse informerer AS'et om, at enheden er blevet tilgængelig efter en kommunikationsfejl. Kan bruges, når der er behov for at overføre data til en enhed, men det forrige forsøg lykkedes ikke, fordi UE ikke svarede på en meddelelse fra netværket (personsøgning), og dataene blev ikke leveret. Hvis denne type overvågning er blevet anmodet om for UE, så snart enheden foretager en indgående kommunikation, laver en TAU eller sender data til uplinket, vil AS'en blive informeret om, at enheden er blevet tilgængelig. Da DDN-proceduren (downlink data notification) fungerer mellem MME og S/P-GW, er denne type overvågning kun tilgængelig for IP-enheder.

PDN-forbindelsesstatus – informerer AS, når enhedens status ændres (PDN-forbindelsesstatus) - forbindelse (PDN-aktivering) eller afbrydelse (PDN-sletning). Dette kan bruges af AS'et til at initiere kommunikation med UE'en eller omvendt for at forstå, at kommunikation ikke længere er mulig. Denne type overvågning er tilgængelig for IP- og ikke-IP-enheder.

Antal UE'er til stede i et geografisk område – Denne type overvågning bruges af AS til at bestemme antallet af UE'er i et bestemt geografisk område.

Enheden udløses)

I 2G/3G-netværk var registreringsproceduren i netværket to-trins: først enheden, der er registreret med SGSN (vedhæftningsprocedure), derefter aktiverede den om nødvendigt PDP-konteksten - en forbindelse med pakkegatewayen (GGSN) at overføre data. I 3G-netværk forekom disse to procedurer sekventielt, dvs. enheden ventede ikke på det øjeblik, hvor den skulle overføre data, men aktiverede PDP umiddelbart efter at vedhæftningsproceduren var afsluttet. I LTE blev disse to procedurer kombineret til én, det vil sige, at enheden ved tilslutning straks anmodede om aktivering af en PDN-forbindelse (analog med PDP i 2G/3G) via eNodeB til MME-SGW-PGW.

NB-IoT definerer en forbindelsesmetode som "vedhæft uden PDN", det vil sige, at UE tilslutter uden at etablere en PDN-forbindelse. I dette tilfælde er den ikke tilgængelig til at transmittere trafik, og den kan kun modtage eller sende SMS. For at sende en kommando til en sådan enhed for at aktivere PDN og oprette forbindelse til AS, blev funktionen "Device triggering" udviklet.

Når SCEF modtager en kommando om at forbinde en sådan UE fra AS'en, starter SCEF at sende en kontrol-SMS til enheden gennem SMS-centret. Når enheden modtager en SMS, aktiverer enheden PDN og forbinder til AS'et for at modtage yderligere instruktioner eller overføre data.

Der kan være tidspunkter, hvor dit enhedsabonnement udløber på SCEF. Ja, abonnementet har sin egen levetid, fastsat af operatøren eller aftalt med AS. Ved udløb vil PDN blive deaktiveret på MME'en, og enheden bliver utilgængelig for AS'en. I dette tilfælde vil funktionen "Device triggering" også hjælpe. Ved modtagelse af nye data fra AS, vil SCEF finde ud af enhedsforbindelsesstatus og levere data via SMS-kanal.

Konklusion

Funktionaliteten af ​​SCEF er naturligvis ikke begrænset til de tjenester, der er beskrevet ovenfor, og den udvikler sig og udvider konstant. I øjeblikket er mere end et dusin tjenester allerede blevet standardiseret til SCEF. Nu har vi kun berørt de vigtigste funktioner, der efterspørges fra udviklere; vi vil tale om resten i fremtidige artikler.

Spørgsmålet opstår straks: hvordan får man testadgang til denne "mirakel"-knude til foreløbig test og fejlretning af mulige sager? Alt er meget enkelt. Enhver udvikler kan indsende en anmodning til [e-mail beskyttet], hvor det er nok at angive formålet med tilslutningen, en beskrivelse af en eventuel sag og kontaktoplysninger til kommunikation.

Indtil næste gang!

Forfattere:

• seniorekspert i afdelingen for konvergente løsninger og multimedietjenester Sergey Novikov sanov,
• ekspert i afdelingen for konvergente løsninger og multimedietjenester Alexey Lapshin aslapsk

Kilde: www.habr.com