I artikkelen "", når vi snakker om arkitekturen til pakkekjernen til NB-IoT-nettverket, nevnte vi utseendet til en ny SCEF-node. Vi forklarer i tredje del hva det er og hvorfor det er nødvendig?
Når du oppretter en M2M-tjeneste, møter applikasjonsutviklere følgende spørsmål:
- hvordan identifisere enheter;
- hvilken verifiserings- og autentiseringsalgoritme som skal brukes;
- hvilken transportprotokoll å velge for å samhandle med enheter;
- hvordan pålitelig levere data til enheter;
- hvordan organisere og etablere regler for utveksling av data med dem;
- hvordan overvåke og få informasjon om deres tilstand på nettet;
- hvordan du samtidig leverer data til en gruppe av enhetene dine;
- hvordan sende data fra én enhet til flere klienter samtidig;
- hvordan du får enhetlig tilgang til ekstra operatørtjenester for å administrere enheten din.
For å løse dem er det nødvendig å lage proprietære teknisk "tunge" løsninger, noe som fører til økte lønnskostnader og time-to-market tjenester. Det er her den nye SCEF-noden kommer til unnsetning.
Som definert av 3GPP, er SCEF (service capability exposure function) en helt ny komponent i 3GPP-arkitekturen hvis funksjon er å på en sikker måte eksponere tjenestene og egenskapene som tilbys av 3GPP nettverksgrensesnitt gjennom APIer.
Med enkle ord er SCEF et mellomledd mellom nettverket og applikasjonsserveren (AS), et enkelt vindu med tilgang til operatørtjenester for å administrere din M2M-enhet i NB-IoT-nettverket gjennom et intuitivt, standardisert API-grensesnitt.
SCEF skjuler kompleksiteten til en operatørs nettverk, og lar applikasjonsutviklere abstrahere bort komplekse, enhetsspesifikke mekanismer for samhandling med enheter.
Ved å transformere nettverksprotokoller til et kjent API for applikasjonsutviklere, letter SCEF API opprettelsen av nye tjenester og reduserer tiden til markedet. Den nye noden inkluderer også funksjoner for å identifisere/autentisere mobile enheter, definere reglene for datautveksling mellom enheten og AS, fjerne behovet for applikasjonsutviklere å implementere disse funksjonene på sin side, flytte disse funksjonene til operatørens skuldre.
SCEF dekker grensesnittene som er nødvendige for autentisering og autorisasjon av applikasjonsservere, opprettholdelse av UE-mobilitet, dataoverføring og enhetsutløsning, tilgang til tilleggstjenester og operatørnettverksmuligheter.
Mot AS er det et enkelt T8-grensesnitt, en API (HTTP/JSON) standardisert av 3GPP. Alle grensesnitt, med unntak av T8, fungerer basert på DIAMETER-protokollen (fig. 1).
T6a – grensesnitt mellom SCEF og MME. Brukes til prosedyrer for mobilitets-/sesjonsadministrasjon, overføring av ikke-IP-data, levering av overvåkingshendelser og mottak av rapporter om dem.
S6t – grensesnitt mellom SCEF og HSS. Nødvendig for abonnentautentisering, autorisasjon av applikasjonsservere, innhenting av en kombinasjon av ekstern ID og IMSI/MSISDN, klargjøring av overvåkingshendelser og mottak av rapporter om dem.
S6m/T4 – grensesnitt fra SCEF til HSS og SMS-C (3GPP definerer MTC-IWF-noden, som brukes til enhetstriggering og SMS-overføring i NB-IoT-nettverk. Men i alle implementeringer er funksjonaliteten til denne noden integrert i SCEF, så for å forenkle kretsen, vil vi ikke vurdere den separat). Brukes til å innhente ruteinformasjon for sending av SMS og samhandling med SMS-senteret.
T8 – API-grensesnitt for SCEF-interaksjon med applikasjonsservere. Både kontrollkommandoer og trafikk overføres gjennom dette grensesnittet.
*i virkeligheten er det flere grensesnitt; bare de mest grunnleggende er oppført her. En fullstendig liste er gitt i 3GPP 23.682 (4.3.2 Liste over referansepunkter).
Nedenfor er nøkkelfunksjonene og tjenestene til SCEF:
- koble SIM-kortidentifikatoren (IMSI) til ekstern ID;
- overføring av ikke-IP-trafikk (Non-IP Data Delivery, NIDD);
- gruppeoperasjoner ved hjelp av ekstern gruppe-ID;
- støtte for dataoverføringsmodus med bekreftelse;
- bufring av MO (Mobile Originated) og MT (Mobile Terminated) data;
- autentisering og autorisasjon av enheter og applikasjonsservere;
- samtidig bruk av data fra én UE av flere ASer;
- støtte for spesielle UE-statusovervåkingsfunksjoner (MONTE – Monitoring Events);
- enhetsutløsning;
- gir ikke-IP dataroaming.
Grunnprinsippet for samhandling mellom AS og SCEF er basert på den såkalte ordningen. abonnementer. Hvis det er nødvendig å få tilgang til en hvilken som helst SCEF-tjeneste for en spesifikk UE, må applikasjonsserveren opprette et abonnement ved å sende en kommando til den spesifikke API-en til den forespurte tjenesten og motta en unik identifikator som svar. Deretter vil alle ytterligere handlinger og kommunikasjon med UE innenfor rammen av denne tjenesten finne sted ved å bruke denne identifikatoren.
Ekstern ID: Universell enhetsidentifikator
En av de viktigste endringene i interaksjonsskjemaet mellom AS og enheter når du arbeider gjennom SCEF, er utseendet til en universell identifikator. Nå, i stedet for et telefonnummer (MSISDN) eller IP-adresse, slik tilfellet var i det klassiske 2G/3G/LTE-nettverket, blir enhetsidentifikatoren for applikasjonsserveren "ekstern ID". Det er definert av standarden i et format som er kjent for applikasjonsutviklere " @ "
Utviklere trenger ikke lenger implementere enhetsautentiseringsalgoritmer; nettverket tar fullstendig over denne funksjonen. Ekstern ID er knyttet til IMSI, og utvikleren kan være sikker på at når den får tilgang til en spesifikk ekstern ID, samhandler den med et spesifikt SIM-kort. Ved bruk av SIM-brikke får du en helt unik situasjon når den eksterne IDen identifiserer en spesifikk enhet unikt!
Dessuten kan flere eksterne ID-er kobles til én IMSI - en enda mer interessant situasjon oppstår når den eksterne ID-en unikt identifiserer en spesifikk applikasjon som er ansvarlig for en bestemt tjeneste på en bestemt enhet.
En gruppeidentifikator vises også - ekstern gruppe-ID, som inkluderer et sett med individuelle eksterne IDer. Nå, med én forespørsel til SCEF, kan AS starte gruppeoperasjoner - sende data eller kontrollkommandoer til flere enheter samlet i en enkelt logisk gruppe.
På grunn av det faktum at for AS-utviklere kan overgangen til en ny enhetsidentifikator ikke være øyeblikkelig, forlot SCEF muligheten for AS-kommunikasjon med UE gjennom et standardnummer - MSISDN.
Overføring av ikke-IP-trafikk (Non-IP Data Delivery, NIDD)
I NB-IoT, som en del av optimaliseringen av mekanismer for overføring av små mengder data, i tillegg til de allerede eksisterende PDN-typene, som IPv4, IPv6 og IPv4v6, har det dukket opp en annen type – ikke-IP. I dette tilfellet blir ikke enheten (UE) tildelt en IP-adresse og data overføres uten bruk av IP-protokollen. Trafikk for slike forbindelser kan rutes på to måter: klassisk - MME -> SGW -> PGW og deretter gjennom PtP-tunnelen til AS (fig. 2) eller ved hjelp av SCEF (fig. 3).
Den klassiske metoden gir ingen spesielle fordeler i forhold til IP-trafikk, bortsett fra å redusere størrelsen på overførte pakker på grunn av fraværet av IP-hoder. Bruken av SCEF åpner for en rekke nye muligheter og forenkler prosedyrene for samhandling med enheter betydelig.
Når du overfører data via SCEF, vises to svært viktige fordeler fremfor klassisk IP-trafikk:
Levering av MT-trafikk til enheten via ekstern ID
For å sende en melding til en klassisk IP-enhet, må AS kjenne sin IP-adresse. Her oppstår et problem: siden enheten vanligvis mottar en "grå" IP-adresse ved registrering, kommuniserer den med applikasjonsserveren, som ligger på Internett, gjennom en NAT-node, hvor den grå adressen oversettes til hvit. Kombinasjonen av grå og hvite IP-adresser varer i en begrenset tid, avhengig av NAT-innstillingene. I gjennomsnitt for TCP eller UDP - ikke mer enn fem minutter. Det vil si at hvis det ikke er datautveksling med denne enheten innen 5 minutter, vil forbindelsen gå i oppløsning og enheten vil ikke lenger være tilgjengelig på den hvite adressen som økten med AS ble startet med. Det er flere løsninger:
1. Bruk hjerteslag. Når en tilkobling er opprettet, må enheten utveksle pakker med AS med noen få minutter, og dermed forhindre at NAT-oversettelser lukkes. Men det kan ikke være snakk om noen energieffektivisering her.
2. Hver gang, om nødvendig, sjekk tilgjengeligheten av pakker for enheten på AS - send en melding til opplinken.
3. Opprett en privat APN (VRF), der applikasjonsserveren og enhetene vil være på samme subnett, og tilordne statiske IP-adresser til enhetene. Det vil fungere, men det er nesten umulig når vi snakker om en flåte på tusenvis, titusenvis av enheter.
4. Til slutt, det mest passende alternativet: bruk IPv6, det krever ikke NAT, siden IPv6-adresser er direkte tilgjengelige fra Internett. Men selv i dette tilfellet, når enheten registreres på nytt, vil den motta en ny IPv6-adresse og vil ikke lenger være tilgjengelig med den forrige.
Følgelig er det nødvendig å sende en initialiseringspakke med en enhetsidentifikator til serveren for å rapportere den nye IP-adressen til enheten. Vent så på en bekreftelsespakke fra AS, som også påvirker energieffektiviteten.
Disse metodene fungerer godt for 2G/3G/LTE-enheter, der enheten ikke har strenge krav til autonomi og som et resultat av det ikke er noen restriksjoner på sendetid og trafikk. Disse metodene er ikke egnet for NB-IoT på grunn av deres høye energiforbruk.
SCEF løser dette problemet: siden den eneste enhetsidentifikatoren for et AS er en ekstern ID, trenger AS bare å sende en datapakke til SCEF for en spesifikk ekstern ID, og SCEF tar seg av resten. I tilfelle enheten er i PSM- eller eDRX-strømsparingsmodus, vil data bufres og leveres når enheten blir tilgjengelig. Hvis enheten er tilgjengelig for trafikk, vil dataene bli levert umiddelbart. Det samme gjelder ledergrupper.
AS kan når som helst tilbakekalle den bufrede meldingen til UE eller erstatte den med en ny.
Buffermekanismen kan også brukes ved overføring av MO-data fra UE til AS. Dersom SCEF ikke var i stand til å levere data til AS umiddelbart, for eksempel hvis vedlikeholdsarbeid pågår på AS-serverne, vil disse pakkene bli bufret og garantert levert så snart AS blir tilgjengelig.
Som nevnt ovenfor er tilgang til en spesifikk tjeneste og UE for et AS (og NIDD er en tjeneste) regulert av regler og retningslinjer på SCEF-siden, som gir mulighet for den unike muligheten for samtidig bruk av data fra en UE av flere ASer. De. hvis flere AS har abonnert på en UE, vil SCEF etter å ha mottatt data fra UE sende det til alle abonnerte AS. Dette er godt egnet for tilfeller der skaperen av en flåte av spesialiserte enheter deler data mellom flere klienter. For eksempel, ved å opprette et nettverk av værstasjoner som kjører på NB-IoT, kan du selge data fra dem til mange tjenester samtidig.
Garantert meldingsleveringsmekanisme
Reliable Data Service er en mekanisme for garantert levering av MO- og MT-meldinger uten bruk av spesialiserte algoritmer på protokollnivå, som for eksempel håndtrykk i TCP. Den fungerer ved å inkludere et spesielt flagg i tjenestedelen av meldingen når den utveksles mellom UE og SCEF. Om denne mekanismen skal aktiveres ved overføring av trafikk bestemmes av AS.
Hvis mekanismen er aktivert, inkluderer UE et spesielt flagg i overheaddelen av pakken når den krever garantert levering av MO-trafikk. Ved mottak av en slik pakke, svarer SCEF til UE med en bekreftelse. Hvis UE ikke mottar bekreftelsespakken, vil pakken mot SCEF bli sendt på nytt. Det samme skjer for MT-trafikken.
Enhetsovervåking (overvåking av hendelser - MONTE)
Som nevnt ovenfor inkluderer SCEF-funksjonaliteten blant annet funksjoner for å overvåke tilstanden til UE, den såkalte. enhetsovervåking. Og hvis nye identifikatorer og dataoverføringsmekanismer er optimaliseringer (om enn svært alvorlige) av eksisterende prosedyrer, så er MONTE en helt ny funksjonalitet som ikke er tilgjengelig i 2G/3G/LTE-nettverk. MONTE lar AS overvåke enhetsparametere som tilkoblingsstatus, kommunikasjonstilgjengelighet, plassering, roamingstatus, etc. Vi vil snakke om hver mer detaljert litt senere.
Hvis det er nødvendig å aktivere en overvåkingshendelse for en enhet eller gruppe av enheter, abonnerer AS på den tilsvarende tjenesten ved å sende den tilsvarende API MONTE-kommandoen til SCEF, som inkluderer parametere som ekstern ID eller ekstern gruppe-ID, AS-identifikator, overvåking type, antall rapporter, som AS ønsker å motta. Hvis AS er autorisert til å utføre forespørselen, vil SCEF, avhengig av typen, levere hendelsen til HSS eller MME (fig. 4). Når en hendelse inntreffer, genererer MME eller HSS en rapport til SCEF, som sender den til AS.
Tilveiebringelse av alle hendelser, med unntak av "Antall UEer tilstede i et geografisk område", skjer gjennom HSS. To hendelser "Change of IMSI-IMEI Association" og "Roaming Status" spores direkte på HSS, resten vil bli levert av HSS på MME.
Hendelser kan være enten engangs eller periodiske, og bestemmes av typen.
Sending av en rapport om en hendelse (rapportering) utføres av noden som sporer hendelsen direkte til SCEF (fig. 5).
Et viktig poeng: Overvåkingshendelser kan brukes på både ikke-IP-enheter koblet via SCEF og IP-enheter som overfører data på klassisk måte via MME-SGW-PGW.
La oss se nærmere på hver av overvåkingshendelsene:
Tap av tilkobling — informerer AS om at UE ikke lenger er tilgjengelig for verken datatrafikk eller signalering. Hendelsen oppstår når "mobil nåbarhetstidtakeren" for UE utløper på MME. I en forespørsel om denne typen overvåking kan AS indikere sin "Maksimal deteksjonstid"-verdi - hvis UE i løpet av denne tiden ikke viser noen aktivitet, vil AS bli informert om at UE er utilgjengelig, med angivelse av årsaken. Hendelsen oppstår også hvis UE ble tvangsfjernet av nettverket av en eller annen grunn.
* For å informere nettverket om at enheten fortsatt er tilgjengelig, starter den med jevne mellomrom en oppdateringsprosedyre - Tracking Area Update (TAU). Frekvensen for denne prosedyren settes av nettverket ved hjelp av timer T3412 eller (T3412_extended i tilfelle av PSM), hvis verdi blir overført til enheten under Festprosedyren eller neste TAU. Tidtaker for mobil tilgjengelighet er vanligvis flere minutter lenger enn T3412. Hvis UE ikke har laget en TAU før utløpet av "Mobile reachability-timeren", anser nettverket at den ikke lenger er tilgjengelig.
UE tilgjengelighet – Indikerer når UE blir tilgjengelig for DL-trafikk eller SMS. Dette skjer når UE blir tilgjengelig for personsøking (for en UE i eDRX-modus) eller når UE går inn i ECM-CONNECTED-modus (for en UE i PSM- eller eDRX-modus), dvs. lager en TAU eller sender en uplink-pakke.
Stedsrapportering – Denne typen overvåkingshendelser lar AS forespørre plasseringen til UE. Enten gjeldende plassering (Gjeldende plassering) eller sist kjente plassering (bestemt av celle-IDen som enheten laget TAU fra eller overførte trafikk forrige gang) kan forespørres, noe som er relevant for enheter i PSM- eller eDRX-strømsparemodus. For «Gjeldende plassering» kan AS be om gjentatte svar, med MME som informerer AS hver gang enhetens plassering endres.
Endring av IMSI-IMEI Association – Når denne hendelsen er aktivert, begynner SCEF å overvåke endringer i kombinasjonen av IMSI (SIM-kortidentifikator) og IMEI (enhetsidentifikator). Når en hendelse inntreffer, informerer AS. Kan brukes til automatisk å binde en ekstern ID på nytt til en enhet under planlagt erstatningsarbeid eller tjene som en identifikator for tyveri av en enhet.
Roamingstatus – denne typen overvåking brukes av AS for å bestemme om UE er i hjemmenettverket eller i nettverket til en roamingpartner. Eventuelt kan PLMN (Public Land Mobile Network) til operatøren som enheten er registrert hos, overføres.
Kommunikasjonsfeil — Denne typen overvåking informerer AS om feil i kommunikasjonen med enheten, basert på årsakene til tilkoblingstapet (frigjøringsårsakskode) mottatt fra radioaksessnettet (S1-AP-protokoll). Denne hendelsen kan bidra til å avgjøre hvorfor kommunikasjonen mislyktes - på grunn av problemer på nettverket, for eksempel når eNodeb er overbelastet (radioressurser ikke tilgjengelig) eller på grunn av feil på selve enheten (Radio Connection With UE Lost).
Tilgjengelighet etter DDN-feil – denne hendelsen informerer AS om at enheten er blitt tilgjengelig etter en kommunikasjonsfeil. Kan brukes når det er behov for å overføre data til en enhet, men det forrige forsøket var ikke vellykket fordi UE ikke svarte på et varsel fra nettverket (personsøking) og dataene ble ikke levert. Hvis denne typen overvåking er forespurt for UE, så snart enheten gjør en innkommende kommunikasjon, gjør en TAU eller sender data til opplinken, vil AS bli informert om at enheten er blitt tilgjengelig. Siden DDN (downlink data notification)-prosedyren fungerer mellom MME og S/P-GW, er denne typen overvåking kun tilgjengelig for IP-enheter.
PDN-tilkoblingsstatus – informerer AS når enhetens status endres (PDN-tilkoblingsstatus) - tilkobling (PDN-aktivering) eller frakobling (PDN-sletting). Dette kan brukes av AS for å initiere kommunikasjon med UE, eller omvendt, for å forstå at kommunikasjon ikke lenger er mulig. Denne typen overvåking er tilgjengelig for IP- og ikke-IP-enheter.
Antall UEer i et geografisk område – Denne typen overvåking brukes av AS for å bestemme antall UEer i et bestemt geografisk område.
Enhetsutløsning)
I 2G/3G-nettverk var registreringsprosedyren i nettverket to-trinns: først enheten registrert med SGSN (vedleggsprosedyre), deretter, om nødvendig, aktiverte den PDP-konteksten - en forbindelse med pakkeporten (GGSN) å overføre data. I 3G-nettverk skjedde disse to prosedyrene sekvensielt, dvs. enheten ventet ikke på øyeblikket da den trengte å overføre data, men aktiverte PDP umiddelbart etter at vedleggsprosedyren var fullført. I LTE ble disse to prosedyrene kombinert til én, det vil si at når enheten ble koblet til, ba enheten umiddelbart om aktivering av PDN-forbindelsen (analog med PDP i 2G/3G) via eNodeB til MME-SGW-PGW.
NB-IoT definerer en tilkoblingsmetode som "feste uten PDN", det vil si at UE kobler til uten å etablere en PDN-tilkobling. I dette tilfellet er den ikke tilgjengelig for overføring av trafikk, og kan kun motta eller sende SMS. For å sende en kommando til en slik enhet for å aktivere PDN og koble til AS, ble funksjonaliteten "Device triggering" utviklet.
Ved mottak av en kommando om å koble til en slik UE fra AS, starter SCEF å sende en kontroll-SMS til enheten gjennom SMS-senteret. Når du mottar en SMS, aktiverer enheten PDN og kobler til AS for å motta ytterligere instruksjoner eller overføre data.
Det kan være tider når enhetsabonnementet ditt utløper på SCEF. Ja, abonnementet har sin egen levetid, fastsatt av operatøren eller avtalt med AS. Ved utløp vil PDN bli deaktivert på MME og enheten vil bli utilgjengelig for AS. I dette tilfellet vil funksjonaliteten "Device triggering" også hjelpe. Ved mottak av nye data fra AS vil SCEF finne ut enhetens tilkoblingsstatus og levere dataene via SMS-kanal.
Konklusjon
Funksjonaliteten til SCEF er selvfølgelig ikke begrenset til tjenestene beskrevet ovenfor og er i stadig utvikling og utvidelse. For øyeblikket er mer enn et dusin tjenester allerede standardisert for SCEF. Nå har vi bare berørt hovedfunksjonene som er etterspurt fra utviklere; vi vil snakke om resten i fremtidige artikler.
Spørsmålet oppstår umiddelbart: hvordan få testtilgang til denne "mirakel"-noden for foreløpig testing og feilsøking av mulige tilfeller? Alt er veldig enkelt. Enhver utvikler kan sende inn en forespørsel til [e-postbeskyttet], der det er nok å angi formålet med tilkoblingen, en beskrivelse av en mulig sak og kontaktinformasjon for kommunikasjon.
Til neste gang!
Forfattere:
- seniorekspert ved avdelingen for konvergente løsninger og multimedietjenester Sergey Novikov ,
- ekspert på avdelingen for konvergente løsninger og multimedietjenester Alexey Lapshin
Kilde: www.habr.com