I artiklen "", nævnte vi i beskrivelsen af arkitekturen for NB-IoT-netværkets pakke-kernel fremkomsten af den nye SCEF-komponent. I den tredje del forklarer vi, hvad det er, og hvorfor det er nødvendigt?
Når der oprettes en M2M-tjeneste, står applikationsudviklere over for følgende spørgsmål:
- hvordan man identificerer enheder;
- hvilken algoritme man skal bruge til validering og autentificering;
- hvilken transportprotokol man skal vælge til interaktion med enhederne;
- hvordan man sikkert sender data til enhederne;
- hvordan man organiserer og fastlægger reglerne for datakommunikation med dem;
- hvordan man overvåger og i realtid får information om deres tilstand;
- hvordan man samtidig leverer data til en gruppe af sine enheder;
- hvordan man samtidig sender data fra en enhed til flere kunder;
- hvordan man får en ensartet adgang til operatørens ekstra tjenester til styring af ens enhed.
For at løse disse problemer er man nødt til at skabe proprietære tekniske "tunge" løsninger, hvilket fører til øgede arbejdsbyrder og længere time-to-market for tjenesterne. Her kommer den nye SCEF-enhed til hjælp.
Ifølge 3GPP's definition er SCEF (service capability exposure function) en helt ny komponent i 3GPP-arkitekturen, hvis funktion er sikkert at eksponere de tjenester og muligheder, der leveres gennem 3GPP-netværksinterface via API.
Enkelt sagt er SCEF en mellemmand mellem netværket og applikationsserveren (application server – AS), et samlet vindue for adgang til operatørens tjenester til styring af ens M2M-enhed i NB-IoT-netværket gennem et intuitivt, standardiseret API-interface.
SCEF skjuler kompleksiteten af operatørens netværk og gør det muligt for applikationsudviklere at abstrahere fra de komplekse, specifikke interaktionsmekanismer med enhederne.
Ved at konvertere netværksprotokoller til et velkendt API-grænseflade for udviklere letter SCEF oprettelsen af nye tjenester og reducerer time-to-market. Den nye node inkluderer også funktioner til identifikation/autentificering af mobile enheder og fastsættelse af regler for datadetion mellem enheden og AS, hvilket fjerner behovet for udviklere at implementere disse funktioner selv og i stedet overlader dem til operatøren.
SCEF fungerer som en central grænseflade for autentificering og autorisation af applikationsservere, understøttelse af mobilitet for UE, datatransmission og enhedstriggere, adgang til ekstra tjenester og netværksmuligheder.
Der er kun én enkelt grænseflade T8 mod AS, API-grænsefladen (HTTP/JSON), standardiseret af 3GPP. Alle grænseflader, undtagen T8, arbejder på basis af protokol DIAMETER (se figur 1).
T6a – grænsefladen mellem SCEF og MME. Bruges til procedurer for mobilitets-/sessionsstyring, overførsel af non-IP data, provisioning af overvågningshændelser og modtagelse af rapporter om dem.
S6t – grænsefladen mellem SCEF og HSS. Nødvendig for autentificering af abonnenter, autorisering af applikationsservere, modtagelse af båndet ekstern ID og IMSI/MSISDN, provisioning af overvågningshændelser og modtagelse af rapporter om dem.
S6m/T4 – grænseflader fra SCEF til HSS og SMS-C (i 3GPP defineres en node MTC-IWF, som bruges til enhedstriggere og SMS-overførsel i NB-IoT-netværk. Men i alle implementeringer er denne nodes funktionalitet integreret i SCEF, så for at forenkle diagrammet vil vi ikke behandle det separat). De bruges til at modtage ruteoplysninger til sending af SMS og interaktion med SMS-centret.
T8 – API-grænsefladen til interaktion mellem SCEF og applikationsservere. Gennem denne grænseflade sendes både kontrolkommandoer og trafik.
*Der er faktisk flere grænseflader, her er kun de mest grundlæggende angivet. Den fulde liste findes i 3GPP 23.682 (4.3.2 Liste over referencepunkter).
Nedenfor er de nøglefunktioner og -tjenester, SCEF tilbyder:
- binding af SIM-kortets identificering (IMSI) til ekstern ID;
- overførsel af non-IP trafik (Non-IP Data Delivery, NIDD);
- gruppeoperationer, ved brug af ekstern gruppe-ID;
- understøttelse af bekræftet datatransmission;
- buffering af MO (Mobile Originated) og MT (Mobile Terminated) data;
- autentificering og autorisation af enheder og applikationsservere;
- samtidig brug af data fra en UE af flere AS;
- understøttelse af særlige funktioner til overvågning af UE's tilstand (MONTE – Overvågningsbegivenheder);
- triggering af enheder;
- sikring af roaming af non-IP data.
Det grundlæggende princip for interaktionen mellem AS og SCEF er baseret på en såkaldt abonnementsmodel. Ved behov for adgang til en given service for en bestemt UE skal applikationsserveren oprette et abonnement ved at sende en kommando til den specifikke API for den ønskede service og modtage et unikt identifikationsnummer som svar. Herefter vil alle yderligere handlinger og kommunikation med UE inden for denne service ske ved hjælp af dette identifikationsnummer.
Ekstern ID: universelt identifikationsnummer for enheden
En af de vigtigste ændringer i måden AS interagerer med enheder via SCEF er introduktionen af et universelt identifikationsnummer. Nu bliver enhedens identifikator for applikationsserveren "ekstern ID" i stedet for telefonnummeret (MSISDN) eller IP-adressen, som det var i det klassiske netværk 2G/3G/LTE. Det defineres som standard i et format, der er velkendt for applikationsudviklere "@".
Udviklere har ikke længere behov for at implementere autentifikationsalgoritmer for enhederne, da netværket fuldstændigt overtager denne funktion. Den eksterne ID knyttes til IMSI, og udvikleren kan være sikker på, at ved at henvende sig til en bestemt ekstern ID, interagerer de med et specifikt SIM-kort. Ved brug af et SIM-chip opstår der endda en unik situation, hvor den eksterne ID entydigt identificerer den specifikke enhed!
Desuden kan flere eksterne ID'er knyttes til en enkelt IMSI — hvilket skaber en endnu mere interessant situation, hvor den eksterne ID entydigt identificerer en bestemt applikation, der er ansvarlig for en specifik service på en bestemt enhed.
Derudover introduceres en gruppeidentifikator — ekstern gruppe-ID, som inkluderer et sæt separate eksterne ID'er. Nu kan en enkelt anmodning til SCEF tillade AS at igangsætte gruppeoperationer — sending af data eller kontrolkommandoer til mange enheder samlet i en enkelt logisk gruppe.
Da skiftet til det nye enhedsidentifikationsnummer ikke kan være øjeblikkeligt for udviklerne af AS, har SCEF efterladt muligheden for kommunikation mellem AS og UE via det almindelige nummer – MSISDN.
Overførsel af non-IP trafik (Non-IP Data Delivery, NIDD)
I NB-IoT, i forbindelse med optimering af mekanismer til overførsel af små datamængder, er der kommet en ny type PDN til ud over de eksisterende typer som IPv4, IPv6 og IPv4v6 — non-IP. I dette tilfælde tildeles enheden (UE) ikke en IP-adresse, og data overføres uden brug af IP-protokollen. Trafik til sådanne forbindelser kan rutes på to måder: den klassiske — MME -> SGW -> PGW og derefter gennem PtP tunnel til AS (figur 2) eller ved brug af SCEF (figur 3).
Den klassiske metode giver ikke store fordele i forhold til IP-trafik, bortset fra at størrelsen af de overførte pakker reduceres på grund af manglende IP-overskrifter. Brugen af SCEF åbner derimod for en række nye muligheder og forenkler interaktionsprocedurerne med enhederne.
Når data overføres gennem SCEF, opstår der to meget vigtige fordele i forhold til klassisk IP-trafik:
Levering af MT trafik til enheden via ekstern ID
For at sende en besked til en klassisk IP-enhed — skal AS kende dens IP-adresse. Her opstår problemet: da enheden ved registrering normalt får en 'grå' IP-adresse, kommunikerer den med applikationsserveren, som er placeret på internettet, gennem en NAT-node, hvor den grå adresse oversættes til en hvid. Forbindelsen mellem grå og hvid IP-adresse opretholdes i en begrænset tid, afhængigt af NAT-indstillingerne. I gennemsnit for TCP eller UDP — ikke længere end fem minutter. Det vil sige, at hvis der ikke har været datatransmission med denne enhed i 5 minutter, vil forbindelsen bryde sammen, og enheden vil ikke være tilgængelig via den hvide adresse, som sessionen med AS blev indgået med. Der er flere løsninger:
1. Bruge heartbeat. Når forbindelsen først er etableret, skal enheden udveksle pakker med AS hvert par minutter, så oversættelsen på NAT ikke lukkes. Men her kan der ikke være tale om nogen form for energieffektivitet.
2. Hver gang det er nødvendigt, kontrollere for tilstedeværelsen af pakker til enheden på AS — sende en besked i uplink.
3. Oprette en privat APN (VRF), hvor applikationsserveren og enhederne vil befinde sig i det samme subnet, og tildele statiske IP-adresser til enhederne. Dette vil fungere, men det er næsten urealistisk, når det drejer sig om en park af tusinder, titusinder af enheder.
4. Endelig er den mest hensigtsmæssige mulighed: at bruge IPv6, da der ikke er behov for NAT, da IPv6-adresser er direkte tilgængelige fra internettet. Dog, selv i dette tilfælde, vil enhedens IPv6-adresse ændre sig ved genregistrering, og den vil ikke længere være tilgængelig via den tidligere adresse.
Derfor er det nødvendigt at sende en slags initialiseringspakke med enhedens identifikator til serveren for at informere om den nye IP-adresse for enheden. Derefter venter man på en bekræftelsespakke fra AS, hvilket også påvirker energieffektiviteten.
Disse metoder fungerer godt for 2G/3G/LTE-enheder, hvor der ikke er strenge krav til enhedens batterilevetid, og dermed er der ingen begrænsninger på airtime og trafik. For NB-IoT er disse metoder ikke anvendelige på grund af deres høje energiforbrug.
SCEF løser dette problem: da den eneste enhedsidentifikator for AS er external ID, er det tilstrækkeligt for AS at sende en datapakke til SCEF for en bestemt external ID, og SCEF håndterer resten. Hvis enheden er i strømbesparende tilstand (PSM) eller eDRX, vil data blive buffere og leveret, når enheden bliver tilgængelig. Hvis enheden er tilgængelig for trafik, vil data blive leveret omgående. Det samme gælder for kontrolkommandoer.
Når som helst kan AS tilbagekalde den buffere meddelelse til UE eller erstatte den med en ny.
Buffer-mekanismen kan også anvendes, når man sender MO-data fra UE til AS. Hvis SCEF ikke kunne levere dataene til AS straks, for eksempel under servicearbejde på AS-serverne, vil disse pakker blive buffere og garanteret leveret, så snart AS bliver tilgængelig.
Som nævnt tidligere reguleres adgangen til en bestemt tjeneste og UE for AS (og NIDD – det er en tjeneste) af regler og politikker på SCEF-siden, hvilket muliggør muligheden for samtidig brug af data fra en enkelt UE af flere AS. Det vil sige, hvis flere AS har tilmeldt sig en UE, vil SCEF efter modtagelse af data fra UE sende dem til alle tilmeldte AS. Dette er godt egnet til tilfælde, hvor skaberen af en række specialiserede enheder deler data mellem flere kunder. For eksempel, ved at oprette et netværk af vejrstationer, der arbejder på NB-IoT, kan man sælge data fra dem til mange tjenester samtidigt.
Mekanismen for garanteret leverings af beskeder
Reliable Data Service — mekanismen for garanteret levering af MO og MT beskeder uden brug af specialiserede algoritmer på protokolniveau, såsom handshake i TCP. Den fungerer ved at inkludere et særligt flag i kontrolfeltet for beskeden under udvekslingen mellem UE og SCEF. Det er AS, der beslutter, om mekanismen skal aktiveres eller ej ved trafikoverførsel.
Hvis mekanismen er aktiveret, inkluderer UE et særligt flag i kontrolfeltet for pakken, når der er behov for garanteret levering af MO trafik. Ved modtagelse af en sådan pakke svarer SCEF med en bekræftelse til UE. Hvis UE ikke modtager en pakke med bekræftelse, vil pakken blive sendt igen mod SCEF. Det samme gælder for MT trafik.
Overvågning af enheder (monitoring events - MONTE)
Som nævnt tidligere omfatter SCEF’s funktionalitet udover andet funktioner til at kontrollere tilstanden af UE, det vil sige overvågning af enheder. Hvis nye identifikatorer og dataoverførselsmekanismer er optimeringer (om end meget alvorlige) af allerede eksisterende procedurer, 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 enhedens parametre som forbindelsesstatus, tilgængelighed for kommunikation, placering, roamingstatus mv. Vi vil senere uddybe hver enkelt parameter.
For at aktivere en overvågningshændelse for en enhed eller en gruppe af enheder, tilmelder AS sig den relevante tjeneste ved at sende en kommando til SCEF via den relevante MONTE API, som inkluderer parametre som external Id eller external group ID, AS identifikatoren, type overvågning, antal rapporter som AS ønsker at modtage. Hvis AS er autoriseret til at udføre anmodningen, provisionerer SCEF hændelsen på HSS eller MME afhængigt af typen (se figur 4). Ved hændelsens indtræden genererer MME eller HSS en rapport til SCEF, som sender den til AS.
Provisionering af alle hændelser, undtagen "Number of UEs present in a geographic area", sker gennem HSS. To hændelser, "Change of IMSI-IMEI Association" og "Roaming Status" overvåges direkte på HSS, mens de øvrige provisioneres af HSS til MME.
Hændelserne kan være engangshændelser eller periodiske, afhængigt af deres type.
Rapportering af hændelser foretages af noden, der overvåger hændelsen, direkte til SCEF (fig. 5).
Vigtig pointe: overvågningshændelser kan anvendes både til non-IP-enheder, der tilsluttes via SCEF, og til IP-enheder, der overfører data på traditionel måde gennem MME-SGW-PGW.
Lad os se nærmere på hver af overvågningshændelserne:
Tab af forbindelse — informerer AS om, at UE ikke længere er tilgængelig for hverken data-trafik eller signaludveksling. Hændelsen indtræffer, når "mobile reachability timer" for UE udløber på MME. I anmodningen om denne type overvågning kan AS angive sin egen værdi for "Maximum Detection Time" — hvis UE ikke viser nogen aktivitet inden for denne tid, vil AS blive informeret om, at UE er utilgængelig, med angivelse af årsagen. Hændelsen indtræffer også, hvis UE af en eller anden grund er blevet tvunget ud af netværket.
* For at netværket skal vide, at enheden stadig er tilgængelig, initierer den periodisk en opdateringsprocedure — Tracking Area Update (TAU). Frekvensen for denne procedure bestemmes af netværket ved hjælp af timer T3412 eller (T3412_extended i tilfælde af PSM), hvis værdi overføres til enheden under proceduren Attach eller den næste TAU. Mobile reachability timer er normalt nogle få minutter længere end T3412. Hvis UE ikke har udført TAU inden for udløbet af "Mobile reachability timer", betragter netværket den som utilgængelig.
UE tilgængelighed – Viser, hvornår UE bliver tilgængelig for DL-trafik eller SMS. Dette sker, når UE bliver tilgængelig for paging (for UE i eDRX-tilstand) eller når UE går til ECM-CONNECTED tilstand (for UE i PSM eller eDRX tilstand), dvs. gør TAU eller sender en uplink-pakke.
Placering rapportering – Denne type overvågningshændelser tillader AS at anmode om data om UE's placering. Enten den nuværende placering (Current Location) eller den senest kendte (Last Known Location, bestemmes ud fra cell ID, som enheden sidst gjorde TAU eller overførte trafik fra), hvilket er relevant for enheder i energibesparende tilstande som PSM eller eDRX. For "Current Location" kan AS anmode om gentagne rapporter, hvormed MME vil informere AS hver gang, enheden skifter placering.
Ændring af IMSI-IMEI-tilknytning – Når denne begivenhed aktiveres, begynder SCEF at overvåge ændringer i båndet mellem IMSI (SIM-kortets identifikator) og IMEI (enhedens identifikator). Når begivenheden indtræffer, informerer den AS. Kan bruges til automatisk at ompræsentere external ID til enheden under planlagte vedligeholdelsesarbejder eller fungere som en identifikator for tyveri af enheden.
Roamingstatus – Denne slags overvågning bruges af AS for at bestemme, om UE er i hjemmenetværket eller i netværket af en roamingpartner. PLMN (Public Land Mobile Network) fra den operatør, hvor enheden er registreret, kan også overføres valgfrit.
Kommunikationsfejl — Denne type overvågning informerer AS om fejl i kommunikationen med enheden, baseret på årsagerne til forbindelsesbrud (release cause code) modtaget fra det radiotilgangsnetværk (S1-AP-protokol). Denne begivenhed kan hjælpe med at fastslå, hvorfor kommunikationsfejlen opstod – enten på grund af problemer i netværket, for eksempel ved overbelastning af eNodeb (Radio resources not available), eller på grund af en fejl i selve enheden (Radio Connection With UE Lost).
Tilgængelighed efter DDN-fejl – Denne begivenhed informerer AS om, at enheden er blevet tilgængelig efter en kommunikationsfejl. Kan bruges, når det er nødvendigt at overføre data til enheden, men den tidligere forsøg var ikke vellykket, da UE ikke svarede på netværksnotifikationer (paging), og dataene ikke blev leveret. Hvis denne type overvågning er anmodet for UE, vil AS blive informeret, når enheden foretager en indkommende kommunikation, udfører TAU eller sender data i uplink. 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 om ændringen af enhedens status (PDN connectivity status) – tilslutning (aktivering af PDN) eller frakobling (fjernelse af PDN). Dette kan bruges af AS til at initiere kommunikation med UE, eller omvendt, for at forstå, at kommunikation ikke længere er mulig. Denne type overvågning er tilgængelig for både IP- og non-IP-enheder.
Antal UEs til stede i et geografisk område – Denne type overvågning bruges af AS for at bestemme antallet af UE i et bestemt geografisk område.
Enhedstriggere (Device triggering))
I 2G/3G netværkene var registreringsproceduren i netværket to-trins: først blev enheden registreret i SGSN (attach-proceduren), og derefter, når det var nødvendigt at overføre data, aktiverede den PDP-konteksten – forbindelsen til pakkegatewayen (GGSN). I 3G-netværk blev disse to procedurer udført sekventielt, dvs. enheden ventede ikke på at skulle overføre data, men aktiverede PDP straks efter afslutningen af attach-proceduren. I LTE blev disse to procedurer samlet til én, hvilket betyder, at enheden straks anmodede om aktivering af PDN-forbindelsen (tilsvarende PDP i 2G/3G) via eNodeB til MME-SGW-PGW.
I NB-IoT er en metode til tilslutning defineret som "attach without PDN", hvilket betyder, at UE foretager attach uden at etablere PDN-forbindelse. I dette tilfælde er den ikke tilgængelig for trafikoverførsel og kan kun modtage eller sende SMS. For at sende en kommando til en sådan enhed for at aktivere PDN og forbinde til AS er funktionen "Device triggering" blevet udviklet.
Når AS modtager en kommando om at forbinde en sådan UE, initierer SCEF via SMS-centeret afsendelsen af en styringssms til enheden. Når enheden modtager SMS, aktiverer den PDN og forbinder til AS for at få efterfølgende instruktioner eller overføre data.
Der kan forekomme tilfælde, hvor abonnementet på enheden udløber på SCEF. Ja, abonnementet har en livscyklus, der er fastsat af operatøren eller aftalt med AS. Når det udløber, vil PDN blive deaktiveret på MME, og enheden bliver utilgængelig for AS. I dette tilfælde vil funktionen "Device triggering" også være nyttig. Når SCEF modtager nye data fra AS, vil den undersøge status for enhedens forbindelse og levere data via SMS-kanalen.
Konklusion
SCEF-funktionen er naturligvis ikke begrænset til de ovenfor beskrevne tjenester og udvikler sig konstant og udvides. I øjeblikket er der allerede standardiseret mere end et dusin tjenester for SCEF. I dag har vi kun berørt de grundlæggende og efterspurgte funktioner fra udviklernes side; de øvrige vil vi diskutere i fremtidige artikler.
Det rejser straks spørgsmålet om, hvordan man får testadgang til denne "mirakel"-node til forudgående testning og fejlfinding af mulige cases? Det er meget enkelt. Enhver udvikler kan sende en anmodning til iot.info@mts.ru, som blot skal angive formålet med forbindelsen, en beskrivelse af den mulige case og kontaktinformation til kommunikation.
På gensyn!
Forfattere:
- Senior ekspert inden for konvergerende løsninger og multimedietjenester Sergey Novikov ,
- Ekspert inden for konvergerende løsninger og multimedietjenester Alexey Lapshin
Kilde: habr.com
