Artikkelissa "", puhuessamme NB-IoT-verkon pakettiytimen arkkitehtuurista, mainitsimme uuden SCEF-solmun ilmestymisen. Selitämme kolmannessa osassa, mikä se on ja miksi sitä tarvitaan?
M2M-palvelua luodessaan sovelluskehittäjät kohtaavat seuraavat kysymykset:
- kuinka tunnistaa laitteet;
- mitä varmennus- ja todennusalgoritmia käytetään;
- mikä siirtoprotokolla valita vuorovaikutuksessa laitteiden kanssa;
- kuinka tiedot toimitetaan luotettavasti laitteisiin;
- kuinka järjestää ja vahvistaa säännöt tietojen vaihtamiseksi heidän kanssaan;
- kuinka seurata ja saada tietoa heidän tilastaan verkossa;
- kuinka toimittaa tietoja samanaikaisesti laitteidesi ryhmään;
- kuinka lähettää tietoja samanaikaisesti yhdestä laitteesta useille asiakkaille;
- kuinka saada yhtenäinen pääsy operaattorin lisäpalveluihin laitteesi hallintaa varten.
Niiden ratkaisemiseksi on tarpeen luoda omia teknisesti "raskaita" ratkaisuja, mikä johtaa kohonneisiin työvoimakustannuksiin ja palveluiden markkinoille tuloon. Tässä uusi SCEF-solmu tulee apuun.
3GPP:n määrittämänä SCEF (service Capability Exposition Function) on täysin uusi 3GPP-arkkitehtuurin komponentti, jonka tehtävänä on paljastaa turvallisesti 3GPP-verkkorajapintojen tarjoamat palvelut ja ominaisuudet API:iden kautta.
Yksinkertaisesti sanottuna SCEF on välittäjä verkon ja sovelluspalvelimen (AS) välillä, yksi ikkuna, josta pääsee operaattoripalveluihin M2M-laitteen hallintaan NB-IoT-verkossa intuitiivisen, standardoidun API-rajapinnan kautta.
SCEF piilottaa operaattorin verkon monimutkaisuuden, jolloin sovelluskehittäjät voivat abstraktion poistaa monimutkaisista, laitekohtaisista mekanismeista vuorovaikutuksessa laitteiden kanssa.
Muuttamalla verkkoprotokollat sovelluskehittäjille tutuksi API:ksi, SCEF API helpottaa uusien palveluiden luomista ja lyhentää markkinoilletuloaikaa. Uusi solmu sisältää myös toimintoja mobiililaitteiden tunnistamiseen/autentikointiin, laitteen ja AS:n välisen tiedonsiirron sääntöjen määrittelyyn, poistaen sovelluskehittäjien tarpeen toteuttaa näitä toimintoja omalla puolellaan, siirtämällä nämä toiminnot operaattorin harteille.
SCEF kattaa sovelluspalvelimien autentikointiin ja valtuutukseen tarvittavat rajapinnat, UE:n liikkuvuuden ylläpitämiseen, tiedonsiirtoon ja laitteiden laukaisuun, lisäpalveluihin pääsyyn ja operaattorin verkkoominaisuuksiin.
AS:ta kohti on yksi T8-liitäntä, API (HTTP/JSON), joka on standardoitu 3GPP:llä. Kaikki liitännät, paitsi T8, toimivat DIAMETER-protokollan perusteella (kuva 1).
T6a – liitäntä SCEF:n ja MME:n välillä. Käytetään liikkuvuuden/istunnon hallintamenettelyihin, ei-IP-tietojen siirtoon, seurantatapahtumien tarjoamiseen ja niistä koskevien raporttien vastaanottamiseen.
S6t – liitäntä SCEF:n ja HSS:n välillä. Tarvitaan tilaajatodennukseen, sovelluspalvelimien valtuutukseen, ulkoisen tunnuksen ja IMSI/MSISDN:n yhdistelmän hankkimiseen, seurantatapahtumien provisiointiin ja niistä koskevien raporttien vastaanottamiseen.
S6m/T4 – liitännät SCEF:stä HSS:ään ja SMS-C:hen (3GPP määrittelee MTC-IWF-solmun, jota käytetään laitteiden laukaisuun ja SMS-lähetykseen NB-IoT-verkoissa. Kuitenkin kaikissa toteutuksissa tämän solmun toiminnallisuus on integroitu SCEF, joten piirin yksinkertaistamiseksi emme käsittele sitä erikseen). Käytetään reititystietojen hankkimiseen tekstiviestien lähettämistä ja tekstiviestikeskuksen kanssa vuorovaikutusta varten.
T8 – API-liitäntä SCEF-vuorovaikutukseen sovelluspalvelimien kanssa. Sekä ohjauskomennot että liikenne välitetään tämän rajapinnan kautta.
*Todellisuudessa käyttöliittymiä on enemmän; tässä on lueteltu vain alkeellisimmat. Täydellinen luettelo on kohdassa 3GPP 23.682 (4.3.2 List of Reference Points).
Alla on SCEFin tärkeimmät toiminnot ja palvelut:
- linkitetään SIM-kortin tunniste (IMSI) ulkoiseen ID:hen;
- ei-IP-liikenteen siirto (Non-IP Data Delivery, NIDD);
- ryhmätoiminnot käyttämällä ulkoista ryhmätunnusta;
- tiedonsiirtotilan tuki vahvistuksella;
- MO (Mobile Originated) ja MT (Mobile Terminated) datan puskurointi;
- laitteiden ja sovelluspalvelimien todennus ja valtuutus;
- yhdestä UE:sta peräisin olevan datan samanaikainen käyttö useiden AS:ien toimesta;
- tuki erityisille UE-tilan valvontatoiminnoille (MONTE – Monitoring Events);
- laitteen laukaisu;
- ei-IP-datavierailujen tarjoaminen.
AS:n ja SCEF:n välisen vuorovaikutuksen perusperiaate perustuu ns. skeemaan. tilauksia. Jos on tarpeen päästä johonkin tietyn UE:n SCEF-palveluun, sovelluspalvelimen on luotava tilaus lähettämällä komento pyydetyn palvelun erityiselle API:lle ja vastaanotettava yksilöllinen tunniste vastauksena. Tämän jälkeen kaikki muut toimet ja viestintä UE:n kanssa tässä palvelussa tapahtuu tätä tunnistetta käyttäen.
Ulkoinen tunnus: yleinen laitetunnus
Yksi tärkeimmistä muutoksista AS:n ja laitteiden välisessä vuorovaikutuksessa SCEF:n kautta työskennellessä on yleisen tunnisteen ilmestyminen. Nyt puhelinnumeron (MSISDN) tai IP-osoitteen sijaan, kuten perinteisessä 2G/3G/LTE-verkossa, sovelluspalvelimen laitetunniste muuttuu "ulkoiseksi tunnisteeksi". Se on standardin määrittelemä sovelluskehittäjille tutussa muodossa. @ "
Kehittäjien ei enää tarvitse ottaa käyttöön laitetodennusalgoritmeja, vaan verkko ottaa tämän toiminnon kokonaan haltuunsa. Ulkoinen tunnus on sidottu IMSI:ään, ja kehittäjä voi olla varma, että kun hän käyttää tiettyä ulkoista tunnusta, se on vuorovaikutuksessa tietyn SIM-kortin kanssa. SIM-sirua käytettäessä saat täysin ainutlaatuisen tilanteen, kun ulkoinen tunnus tunnistaa yksilöllisesti tietyn laitteen!
Lisäksi yhteen IMSI:hen voidaan linkittää useita ulkoisia tunnuksia - vielä mielenkiintoisempi tilanne syntyy, kun ulkoinen tunnus yksilöi yksilöllisesti tietyn sovelluksen, joka vastaa tietystä palvelusta tietyssä laitteessa.
Näkyviin tulee myös ryhmän tunniste - ulkoinen ryhmätunnus, joka sisältää joukon yksittäisiä ulkoisia tunnuksia. Nyt yhdellä pyynnöllä SCEF:lle AS voi aloittaa ryhmätoiminnot - lähettää dataa tai ohjauskomentoja useille laitteille, jotka on yhdistetty yhdeksi loogiseksi ryhmäksi.
Koska AS-kehittäjille siirtyminen uuteen laitetunnisteeseen ei voi olla välitöntä, SCEF jätti mahdollisuuden AS-viestintään UE:n kanssa vakionumeron - MSISDN - kautta.
Ei-IP-liikenteen siirto (Non-IP Data Delivery, NIDD)
NB-IoT:ssä osana pienten tietomäärien siirtomekanismien optimointia jo olemassa olevien PDN-tyyppien, kuten IPv4, IPv6 ja IPv4v6, lisäksi on ilmestynyt toinen tyyppi - ei-IP. Tässä tapauksessa laitteelle (UE) ei osoiteta IP-osoitetta ja tiedot siirretään ilman IP-protokollaa. Tällaisten yhteyksien liikenne voidaan reitittää kahdella tavalla: klassinen - MME -> SGW -> PGW ja sitten PtP-tunnelin kautta AS:lle (kuva 2) tai käyttämällä SCEF:iä (kuva 3).
Klassinen menetelmä ei tarjoa erityisiä etuja IP-liikenteeseen verrattuna, paitsi lähetettyjen pakettien koon pienentäminen IP-otsikoiden puuttumisen vuoksi. SCEF:n käyttö avaa useita uusia mahdollisuuksia ja yksinkertaistaa huomattavasti laitteiden kanssakäymistä.
Kun dataa siirretään SCEF:n kautta, kaksi erittäin tärkeää etua ilmenee perinteiseen IP-liikenteeseen verrattuna:
MT-liikenteen toimitus laitteeseen ulkoisen ID:n kautta
Lähettääkseen viestin klassiseen IP-laitteeseen AS:n on tiedettävä IP-osoitteensa. Tässä syntyy ongelma: koska laite saa yleensä "harmaan" IP-osoitteen rekisteröinnin yhteydessä, se kommunikoi Internetissä sijaitsevan sovelluspalvelimen kanssa NAT-solmun kautta, jossa harmaa osoite muunnetaan valkoiseksi. Harmaan ja valkoisen IP-osoitteiden yhdistelmä kestää rajoitetun ajan NAT-asetuksista riippuen. Keskimäärin TCP:lle tai UDP:lle - enintään viisi minuuttia. Toisin sanoen, jos tämän laitteen kanssa ei tapahdu tiedonvaihtoa 5 minuutin sisällä, yhteys katkeaa ja laitteeseen ei enää pääse käsiksi valkoisesta osoitteesta, jolla istunto AS:n kanssa aloitettiin. Ratkaisuja on useita:
1. Käytä sydämenlyöntiä. Kun yhteys on muodostettu, laitteen on vaihdettava paketteja AS:n kanssa muutaman minuutin välein, mikä estää NAT-käännöksiä sulkemasta. Mutta energiatehokkuudesta tässä ei voi puhua.
2. Tarkasta aina tarvittaessa pakettien saatavuus laitteelle AS:sta - lähetä viesti uplink-linkille.
3. Luo yksityinen APN (VRF), jossa sovelluspalvelin ja laitteet ovat samassa aliverkossa, ja määritä laitteille staattiset IP-osoitteet. Se toimii, mutta se on lähes mahdotonta, kun puhumme tuhansista, kymmenistä tuhansista laitteista.
4. Lopuksi sopivin vaihtoehto: käytä IPv6:ta, se ei vaadi NAT:ia, koska IPv6-osoitteisiin pääsee suoraan Internetistä. Kuitenkin myös tässä tapauksessa, kun laite rekisteröidään uudelleen, se saa uuden IPv6-osoitteen, eikä sitä voi enää käyttää aiemmalla.
Vastaavasti on tarpeen lähettää jokin alustuspaketti laitetunnisteella palvelimelle laitteen uuden IP-osoitteen ilmoittamiseksi. Odota sitten AS:lta vahvistuspakettia, joka vaikuttaa myös energiatehokkuuteen.
Nämä menetelmät toimivat hyvin 2G/3G/LTE-laitteissa, joissa laitteelle ei aseteta tiukkoja autonomiavaatimuksia eikä sen seurauksena ole rajoituksia lähetysajalle ja liikenteelle. Nämä menetelmät eivät sovellu NB-IoT:hen korkean energiankulutuksensa vuoksi.
SCEF ratkaisee tämän ongelman: koska AS:n ainoa laitetunniste on ulkoinen tunnus, AS:n tarvitsee vain lähettää datapaketti SCEF:lle tiettyä ulkoista tunnusta varten, ja SCEF hoitaa loput. Jos laite on PSM- tai eDRX-virransäästötilassa, tiedot puskuroidaan ja toimitetaan, kun laite tulee saataville. Jos laite on liikenteessä käytettävissä, tiedot toimitetaan välittömästi. Sama pätee johtoryhmiin.
AS voi milloin tahansa palauttaa puskuroidun viestin UE:lle tai korvata sen uudella.
Puskurointimekanismia voidaan käyttää myös siirrettäessä MO-dataa UE:sta AS:lle. Jos SCEF ei pystynyt toimittamaan tietoja AS:lle välittömästi, esimerkiksi jos huoltotyöt ovat meneillään AS-palvelimilla, nämä paketit puskuroidaan ja taataan, että ne toimitetaan heti, kun AS tulee saataville.
Kuten edellä todettiin, pääsyä tiettyyn palveluun ja UE:hen AS:lle (ja NIDD on palvelu) säätelevät SCEF-puolen säännöt ja käytännöt, mikä mahdollistaa ainutlaatuisen mahdollisuuden useiden AS:ien samanaikaiseen käyttöön yhdestä UE:sta. Nuo. jos useampi AS on tilannut yhden UE:n, niin saatuaan datan UE:lta SCEF lähettää sen kaikille tilatuille AS:ille. Tämä sopii hyvin tapauksiin, joissa erikoistuneiden laitteiden luoja jakaa tietoja useiden asiakkaiden kesken. Esimerkiksi luomalla NB-IoT:llä toimivien sääasemien verkoston voit myydä niiltä tietoja useille palveluille samanaikaisesti.
Taattu viestin toimitusmekanismi
Reliable Data Service on mekanismi MO- ja MT-sanomien taattua toimitusta varten ilman protokollatason erikoisalgoritmeja, kuten esimerkiksi kättelyä TCP:ssä. Se toimii sisällyttämällä erityisen lipun viestin palveluosaan, kun se vaihdetaan UE:n ja SCEF:n välillä. AS päättää, aktivoidaanko tämä mekanismi liikennettä siirrettäessä.
Jos mekanismi on aktivoitu, UE sisällyttää erityisen lipun paketin ylärajaosaan, kun se vaatii taattua MO-liikenteen toimitusta. Vastaanotettuaan tällaisen paketin SCEF vastaa UE:lle kuittauksella. Jos UE ei vastaanota kuittauspakettia, paketti SCEF:iin lähetetään uudelleen. Sama tapahtuu MT-liikenteessä.
Laitteen valvonta (tapahtumien seuranta – MONTE)
Kuten edellä mainittiin, SCEF-toiminnallisuus sisältää mm. UE:n tilan valvontatoimintoja, ns. laitteen valvonta. Ja jos uudet tunnisteet ja tiedonsiirtomekanismit ovat optimointeja (vaikkakin erittäin vakavia) olemassa oleville menettelyille, niin MONTE on täysin uusi toiminto, jota ei ole saatavilla 2G/3G/LTE-verkoissa. MONTE sallii AS:n valvoa laitteen parametreja, kuten yhteyden tilaa, tiedonsiirron saatavuutta, sijaintia, verkkovierailutilaa jne. Puhumme jokaisesta yksityiskohtaisemmin hieman myöhemmin.
Jos laitteelle tai laiteryhmälle on tarpeen aktivoida jokin valvontatapahtuma, AS tilaa vastaavan palvelun lähettämällä vastaavan API MONTE -komennon SCEF:lle, joka sisältää parametreja, kuten ulkoisen tunnuksen tai ulkoisen ryhmätunnuksen, AS-tunnisteen, valvonnan. tyyppi, raporttien lukumäärä, jotka AS haluaa vastaanottaa. Jos AS on valtuutettu suorittamaan pyyntö, SCEF toimittaa tapahtuman tyypistä riippuen HSS:lle tai MME:lle (kuva 4). Kun tapahtuma tapahtuu, MME tai HSS luo raportin SCEF:lle, joka lähettää sen AS:lle.
Kaikki tapahtumat, lukuun ottamatta "Maantieteellisellä alueella olevien UE:iden lukumäärää", tapahtuu HSS:n kautta. Kahta tapahtumaa "IMSI-IMEI-yhdistyksen muutos" ja "Roaming-tila" seurataan suoraan HSS:ssä, loput HSS tarjoaa MME:ssä.
Tapahtumat voivat olla joko kertaluonteisia tai määräajoin, ja ne määräytyvät niiden tyypin mukaan.
Tapahtumaa jäljittävä solmu suorittaa raportin lähettämisestä tapahtumasta (raportointi) suoraan SCEF:iin (kuva 5).
Tärkeä asia: Valvontatapahtumia voidaan soveltaa sekä ei-IP-laitteisiin, jotka on kytketty SCEF:n kautta, että IP-laitteisiin, jotka lähettävät tietoja perinteisellä tavalla MME-SGW-PGW:n kautta.
Katsotaanpa tarkemmin jokaista seurantatapahtumaa:
Yhteyden katkeaminen — ilmoittaa AS:lle, että UE ei ole enää käytettävissä dataliikenteelle tai signaloinnille. Tapahtuma tapahtuu, kun UE:n "mobiili tavoitettavuusajastin" vanhenee MME:ssä. Tämän tyyppistä valvontaa koskevassa pyynnössä AS voi ilmoittaa "Maksimaalinen havaitsemisaika" -arvonsa - jos UE ei tänä aikana osoita mitään toimintaa, AS saa ilmoituksen, että UE ei ole käytettävissä ja ilmoittaa syyn. Tapahtuma tapahtuu myös, jos verkko jostain syystä poisti UE:n väkisin.
* Ilmoittaakseen verkolle, että laite on edelleen saatavilla, se käynnistää säännöllisesti päivitysmenettelyn - Tracking Area Update (TAU). Tämän toimenpiteen taajuuden määrittää verkko ajastimella T3412 tai (PSM:n tapauksessa T3412_extended), jonka arvo välitetään laitteelle Attach-toimenpiteen tai seuraavan TAU:n aikana. Mobiili tavoitettavuusajastin on yleensä useita minuutteja pidempi kuin T3412. Jos UE ei ole tehnyt TAU:ta ennen "Mobile reachability timer" -ajan päättymistä, verkko katsoo, ettei se ole enää tavoitettavissa.
UE:n saavutettavuus – Ilmaisee, kun UE tulee saataville DL-liikenteelle tai tekstiviesteille. Tämä tapahtuu, kun UE tulee saataville hakua varten (UE:lle eDRX-tilassa) tai kun UE siirtyy ECM-CONNECTED-tilaan (PSM- tai eDRX-tilassa olevalle UE:lle), ts. tekee TAU:n tai lähettää uplink-paketin.
Sijainnin ilmoittaminen – Tämän tyyppisten valvontatapahtumien avulla AS voi kysyä UE:n sijaintia. Joko nykyistä sijaintia (Current Location) tai viimeisintä tunnettua sijaintia (Määrittyy sen solutunnuksen perusteella, josta laite teki TAU:n tai välitti liikennettä viimeksi), voidaan pyytää, mikä on olennaista PSM- tai eDRX-virransäästötilassa oleville laitteille. "Nykyiselle sijainnille" AS voi pyytää toistuvia vastauksia, jolloin MME ilmoittaa AS:lle aina, kun laitteen sijainti muuttuu.
IMSI-IMEI-yhdistyksen muutos – Kun tämä tapahtuma aktivoidaan, SCEF alkaa seurata muutoksia IMSI:n (SIM-kortin tunniste) ja IMEI:n (laitetunniste) yhdistelmässä. Kun tapahtuma tapahtuu, ilmoittaa AS:lle. Voidaan käyttää ulkoisen tunnuksen automaattiseen uudelleensidomiseen laitteeseen ajoitetun vaihtotyön aikana tai toimia laitteen varkauden tunnisteena.
Roaming-tila – AS käyttää tämäntyyppistä valvontaa määrittääkseen, onko UE kotiverkossa vai verkkovierailukumppanin verkossa. Valinnaisesti voidaan lähettää sen operaattorin PLMN (Public Land Mobile Network), johon laite on rekisteröity.
Tiedonsiirron epäonnistuminen — Tämän tyyppinen valvonta ilmoittaa AS:lle tiedonsiirrossa laitteen kanssa olevista virheistä radioliityntäverkosta (S1-AP-protokolla) vastaanotetun yhteyden katkeamisen syiden (release syykoodi) perusteella. Tämä tapahtuma voi auttaa määrittämään, miksi tietoliikenne epäonnistui - verkon ongelmien vuoksi, esimerkiksi kun eNodeb on ylikuormitettu (Radioresurssit eivät ole käytettävissä) tai itse laitteen viasta (Radio Connection With UE Lost).
Saatavuus DDN-vian jälkeen – tämä tapahtuma ilmoittaa AS:lle, että laite on tullut saataville tiedonsiirtohäiriön jälkeen. Voidaan käyttää, kun on tarvetta siirtää tietoja laitteeseen, mutta edellinen yritys ei onnistunut, koska UE ei vastannut verkon ilmoitukseen (haku) eikä tietoja toimitettu. Jos tämän tyyppistä valvontaa on pyydetty UE:lle, niin heti kun laite muodostaa saapuvan viestinnän, tekee TAU:n tai lähettää dataa nousevalle siirtotielle, AS saa tiedon, että laite on tullut saataville. Koska DDN (downlink data notification) -menettely toimii MME:n ja S/P-GW:n välillä, tämän tyyppinen valvonta on käytettävissä vain IP-laitteille.
PDN-yhteyden tila – ilmoittaa AS:lle, kun laitteen tila muuttuu (PDN-yhteyden tila) - yhteys (PDN-aktivointi) tai yhteys katkeaa (PDN-poisto). AS voi käyttää tätä kommunikoinnin aloittamiseen UE:n kanssa tai päinvastoin ymmärtääkseen, että viestintä ei ole enää mahdollista. Tämäntyyppinen valvonta on saatavilla IP- ja ei-IP-laitteille.
Maantieteellisellä alueella olevien UE:iden lukumäärä – AS käyttää tämäntyyppistä valvontaa UE:iden määrän määrittämiseen tietyllä maantieteellisellä alueella.
Laitteen laukaisu)
2G/3G-verkoissa rekisteröintimenettely verkossa oli kaksivaiheinen: ensin laite rekisteröitiin SGSN:ään (attach-menettely), sitten tarvittaessa aktivoitiin PDP-konteksti - yhteys pakettiyhdyskäytävään (GGSN) tiedon lähettämiseen. 3G-verkoissa nämä kaksi toimintoa tapahtuivat peräkkäin, ts. laite ei odottanut hetkeä, jolloin se tarvitsi tiedonsiirtoa, vaan aktivoi PDP:n heti liittämisen jälkeen. LTE:ssä nämä kaksi proseduuria yhdistettiin yhdeksi, eli liitettäessä laite pyysi välittömästi PDN-yhteyden aktivointia (vastaavasti PDP:lle 2G/3G:ssä) eNodeB:n kautta MME-SGW-PGW:hen.
NB-IoT määrittelee yhteysmenetelmän "liitä ilman PDN:ää", eli UE liittyy muodostamatta PDN-yhteyttä. Tässä tapauksessa se ei ole käytettävissä liikenteen välittämiseen, ja se voi vain vastaanottaa tai lähettää tekstiviestejä. Jotta tällaiselle laitteelle voidaan lähettää komento aktivoida PDN ja muodostaa yhteys ASiin, kehitettiin "Laitteen laukaisu" -toiminto.
Vastaanottaessaan komennon kytkeä tällainen UE AS:lta, SCEF aloittaa ohjaustekstiviestin lähettämisen laitteelle SMS-keskuksen kautta. Kun laite vastaanottaa tekstiviestin, se aktivoi PDN:n ja muodostaa yhteyden AS:hen saadakseen lisäohjeita tai siirtääkseen tietoja.
Joskus laitteesi tilaus voi päättyä SCEF:ssä. Kyllä, liittymällä on oma käyttöikä, operaattorin asettama tai AS:n kanssa sovittu. Vanhentuessa PDN deaktivoituu MME:ssä ja laite ei ole AS:n käytettävissä. Tässä tapauksessa "Laitteen laukaisu" -toiminto auttaa myös. Vastaanottaessaan uutta dataa AS:lta SCEF selvittää laitteen yhteyden tilan ja toimittaa tiedot tekstiviestikanavalla.
Johtopäätös
SCEF:n toiminnallisuus ei tietenkään rajoitu yllä kuvattuihin palveluihin, vaan se kehittyy ja laajenee jatkuvasti. Tällä hetkellä SCEFille on standardoitu jo yli tusina palvelua. Nyt olemme käsitelleet vain tärkeimpiä toimintoja, joita kehittäjät vaativat; muista puhumme tulevissa artikkeleissa.
Välittömästi herää kysymys: kuinka saada testipääsy tähän "ihme"-solmuun alustavaa testausta ja mahdollisten tapausten virheenkorjausta varten? Kaikki on hyvin yksinkertaista. Kuka tahansa kehittäjä voi lähettää pyynnön [sähköposti suojattu], jossa riittää mainita yhteyden tarkoitus, kuvaus mahdollisesta tapauksesta ja yhteystiedot viestintää varten.
Kunnes tapaamme jälleen!
Tekijät:
- Konvergenttien ratkaisujen ja multimediapalvelujen osaston vanhempi asiantuntija Sergei Novikov ,
- konvergenttiratkaisujen ja multimediapalveluiden osaston asiantuntija Alexey Lapshin
Lähde: will.com